Hi,

Usually I avoid to make suggestions I don't have the time or knowledge
to implement for myself.  But the world is not a perfect place and it is
full of exceptions:

   Let's forget the primitives .sources and .changes files!

Or to say in another way:

   Let's move on from text-representation of behaviour!

This idea is the base for a lot of changes we need to do:

- Store the sources *inside* the image.  The string is also an object,
isn't it?

- Let use a .changes files ONLY to store the changes not present in the
image.  The .changes has to contains only the modifications made to the
image but still not saved.  That means, for instance, every time we save
the image the .changes goes empty. Note that .changes concept don't
implies text-format, the .changes can be a stream of serialized command
to impact on the image.  For example, all the changes made in the image
but in browsers can be saved (like all the changes a normal user can
make to an image just using the UI).

I recommend everybody to read the chapter about chunk format and the
motivations behind its design in the wonderful Green Book, thanks Stef!.

After doing it, we can move to different representation of behaviour but
text in Smalltalk language, inclusive we have to try other ways to
represent behaviour than text!.   For instance we can experiment with
behavior coming from an event-recorder.

Cheers,

-- Diego

> > Hi andreas
> >
> > Really interesting experiment. We are learning.
> >  Avi we checked with alex, his byte-code loader is now 10 times faster 
> > than cs.
> 
> Cool.  But my guess is that doesn't have that much to do with using 
> byte code rather than source, since compiling is actually fairly fast - 
> and you only need to compile the methods that actually change, which is 
> a very small percentage of the methods MC deals with.
> 
> As far as I can tell, the major bottleneck is in parsing the .mcz files 
> - that was probably responsible for at least 5 minutes of the 9 minutes 
> Andreas reported.  Using a binary format like ReferenceStream or SRP 
> instead would cut this down a lot.  It may be time to move towards 
> that.
> 
> The other thing that takes a lot of time is going back through the 
> .changes file to find the source for the methods that are in the image, 
> ie, in Behavior>>sourceCodeAt:.  Anyone have suggestions of how to 
> speed this up?  It would be cool if we could enable CompiledMethods to 
> optionally hang onto the source string they were compiled with...
> 
> Avi