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