Efficient handling of code (was: News from SqueakFoundation)

Daniel Vainsencher daniel.vainsencher at gmail.com
Sat Jan 14 11:10:16 UTC 2006


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




More information about the Squeak-dev mailing list