Note that the similarity to ginsu is mainly for this specific (very 
trivial) application of the idea. The idea is really intended for 
information that is computed from the code, not loaded from disk.

For example, we could efficiently extend the code model with code 
metrics, type information, senders, smalllint bugs, and make them all 
easily accessible to browsers and other tools...

But making MC faster is also a good goal.

Daniel

stéphane ducasse wrote:
> Hi daniel
> 
> I like the idea. In fact Ginsu model was a bit like that.
> The model was used except if a real entity was there so this goes in  
> that direction.
> The code was accessed then lazily is present.
> 
> Stef
> 
> On 14 janv. 06, at 12:10, Daniel Vainsencher wrote:
> 
>> Avi Bryant wrote:
>> > The single biggest bottleneck in using MC is the time taken to get
>> > the source code and timestamp for a given CompiledMethod.
>>
>> If we want to solve this performance problem, I want to propose  another
>> line of attack - Model Extensions.
>>
>> One of the things that makes Smalltalks great for writing development
>> tools, and therefore a great development environment, is that there is
>> an always available model of the code. It is also very rich, we can  ask
>> it for time-stamps, source-code, parse-trees... unfortunately, we're
>> seeing here that some of these extensions are slow to retrieve/ compute.
>>
>> Andrew Black and I wrote some proposed patterns that attack this  problem
>> (we encountered it implementing one of the Traits browsers). The most
>> important idea is that you should cache stuff only for those code  model
>> elements in which the user is "interested" (for example, some tool is
>> open on them). The tricky thing is to do this so that the tools need
>> almost zero modification for the cache to work efficiently.
>>
>> Applied to this problem, it would allow us to cache exactly the  sources
>> of classes being displayed in any browser, for example.
>>
>> So I would define the bounty as:
>> 1. Make all the information about code that is stored only in the
>> .sources/.changes file into proper Model Extensions
>> 2. Adapt tools to use them where it matters, in particular in MC.
>>
>> Making parse trees into Model Extensions, for example, would make
>> Smalllint significantly faster.
>>
>> BTW, Avi's proposal of having pluggable "source code sources" sounds
>> useful regardless.
>>
>> A current version of the paper is at
>> http://www.technion.ac.il/~danielv/ModelExtensions.pdf
>>
>> Daniel Vainsencher
>>
>> Avi Bryant wrote:
>>
>>> The single biggest bottleneck in using MC is the time taken to  get  
>>> the source code and timestamp for a given CompiledMethod.   For this  
>>> reason, and others - if we're offering bounties, I would  contribute  
>>> some funding to a project to get rid of the dependence  on  the 
>>> .changes file and allow alternate source code storage  schemes (an  
>>> acceptable start would be to simply keep all of the  method source 
>>> as  strings inside the image).
>>> Avi
>>
>>
>>
> 
>