Cheap updates

Richard A. O'Keefe ok at atlas.otago.ac.nz
Wed Jun 7 05:11:56 UTC 2000


	> But for ChangeSets, where only a few methods might be affected, 
	> priming definitely _does_ pay.
	
	Oh well. I guess there are different ways in which the above could be read.
	One is that given the approx. 100 selectors in BBSim you've got a size of
	~420 vs. ~370 bytes per simulated change set. I'm not quite sure how much
	that matters ;-)

If this is one of *many* updates flowing down a wire, it matters.

	Secondly, your example did not include the space required
	for transmitting the information that BBSim was the class affected so your
	scenario was to optimistic in this respect

Not at all, because that information is *the same* for the two methods
of compression.  I succeeded in proving my point that priming _can_
improve compression.

	So why don't you run a somewhat more realistic scenario through all the
	change sets that are out on the server?!

Because I have proved my point.  I have no intention of loading any of those
change sets into my copy of Squeak, because I like stable releases (having
quite enough trouble with my own code).

Note that I make no claim whatsoever that the amazingly simple-minded
priming method I showed is the *best* priming method.  On the contrary,
there's every reason to suspect that a better method can be found.

I have proved my point, and rest content.





More information about the Squeak-dev mailing list