Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
Andrew Tween
amtween at hotmail.com
Thu Jul 16 12:40:06 UTC 2009
Hi Bert,
> From: bert at freudenbergs.de
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
> Date: Thu, 16 Jul 2009 13:40:12 +0200
>
> On 14.07.2009, at 03:01, osp at aloha.com wrote:
>
> > Maybe it is just me, but "a fast bytecode package loader, without
> > the need
> > to compile Smalltalk code" combined with "such feature could make life
> > easier to third party Etoys developer and eventually attract more of
> > them
> > to Etoys" sounds like an endorsement of closed-source commercial
> > EToys.
>
> No, that's is a severe misunderstanding you construct here.
>
> > If
> > commercial success is not the attraction, what is? Faster initial load
> > time? Reduced file transfer size? Perhaps I assumed too much.
>
>
> Yes, both of these. The scenario we care most about is the one million
> kids using XO laptops. These machines are under-powered compared to
> recent PCs, and have rather little main memory. It's infeasible to
> have one image with all the extensions to Etoys, because the whole
> image is loaded into RAM. It would be very nice if these add-ons could
> be delivered as separate packages and loaded on demand.
>
> That's what the current Dr Geo II package is doing. But it is slow,
> because all the code is compiled to byte code when loading the
> package. The Squeak byte code compiler has not exactly been optimized
> for speed, because in usual development you only compile a method at a
> time. In any case, the *result* of loading a package that includes
> both source code and byte code would be exactly the same as compiling
> the source code, but way faster.
>
> This could also be used to speed up package loading in general. In
> fact, this would make the concept of "libraries" feasible in Squeak -
> packages loaded on demand. Think about pre-compiled lisp modules, or
> the .pyc files generated from .py Python files for speed. Note I'm not
> advocating this for Squeak but it would make it technically feasible.
>
> It's just not exactly trivial to do in a robust way. At the very
> least, all global references in the compiled methods will have to be
> updated. This includes classes which have to be referenced, Symbols
> need to get interned and unified. The source could be appended to the
> changes file and source pointers incremented, or the source could
> remain in separate files but we'd need a new source code scheme for
> that.
>
> I think this all would be immensely useful in the long run, but truth
> is we have been getting by without for so long that there just does
> not seem to be anybody both motivated and skilled enough to do it.
I was under the impression that Spoon does this.
i.e. loading Classes/Methods without compilation.
Cheers,
Andy
>
> - Bert -
>
>
>
_________________________________________________________________
With Windows Live, you can organise, edit, and share your photos.
http://clk.atdmt.com/UKM/go/134665338/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090716/718d4c43/attachment.htm
More information about the Squeak-dev
mailing list
|