2014-12-05 14:07 GMT+01:00 Mariano Martinez Peck <marianop...@gmail.com>:
> > > On Fri, Dec 5, 2014 at 6:55 AM, Guillermo Polito < > guillermopol...@gmail.com> wrote: > >> I will summon Martin and Mariano here :). >> >> Introducing fuel in the loading infrastructure had so far AFAIK two >> different experimental setups: >> - tanker: a package completely written in fuel >> > > This one is the one I explain below. > > >> - mixing tanker/fuel with monticello. >> >> > I think here you mean an experiment where we serialized the little thing > MC serializes currently in the data file... > We found that that serialization/materialization is INSIGNIFICANT in the > export/import process. > Ok. > > > Ok... so.. > > Indeed: Tanker. > Fuel is able to serialize methods, classes etc... (but not by default). So > what Tanker does it kind of serialize a whole package (with internal > classes, extension methods, etc) as a fuel file. And then, at the import, > it materializes and then runs a lot of stuff besides the materialization > itself. The idea was NOT to use the Compiler at all at import time, because > that is/was one of the bottleneck when importing packages with Metacello. > The compiler was not needed most of the times, so performance was much > better. However, there were cases (like instVars changed in superclasses > where we are importing) etc.. that causes that we needed to RE-Compile or > stored methods because otherwise the instVar offsets were wrong. This, > COULD be solved this the intermediate representation of Opal and to avoid a > normal compilation. However, I don't remember us doing that. I think we > ended up using the compiler for that scenario. But I am not sure. > What is the state of that for, say, Pharo 4? > > >> However, the results were not so promising I remember. Apparently when >> loading a package, most of the time is spent not in the >> deserialization/recompilation but in the update of the system (system >> dictionary, categories, rpackages, update the corresponding subclass >> relationships). >> > > Exactly. The ones we found that took most of the time was: > > 1) Compiling (could be solved with Fuel and even more if we can fix some > scenarios with Opal) > 2) Notification of created methods/classes. One way to solve this is by > having bulk notifications where we notify a list rather than a single > object. But we should also adapt the observers. > They can be adapted. You can also pile up notifications (well, you can't at the moment, but it would be nice) and have a way to merge them. Such optimisations are also usefull for heavy code generators such as SmaCC. > > 3) #become: when updating/migrating existing instances. > > But...just to see that there is a light in the tunnel, I showed at... mmm > ESUG or PharoConf or.. how to load WHOLE seaside in 10 seconds...which in > my machine takes like 20 minutes. > Which is what I wanted to know :) > > Tanker was originally called "FuelPackageLoader" and was then renamed. > Some useful links with details: > > > http://marianopeck.wordpress.com/2012/08/11/tanker-transporting-packages-with-fuel/ > http://marianopeck.wordpress.com/2012/09/28/new-tanker-current-status/ > > http://marianopeck.wordpress.com/2012/04/28/building-pharo-from-pharokernel-in-10-seconds/ > http://marianopeck.wordpress.com/tag/tanker/ > Thanks for the links! > > http://vimeo.com/63122424 > > > >> >> Just try the following: load a monticello package with (a) no Nautilus >> opened, and with (a) 10 Nautilus opened. >> >> > Exactly!!! Sometimes the slowdown of the notifications is not in the > observable but on the observers ;) > When, in the profile, the observers appear and you can optimize that. One of the way is to have a single central point (i.e. whatever the number of Nautilus instances opened, you send to a singleton), then memoize all queries you do on RPackage and friends before firing again notifications for the views (relevant package, class, etc..). In short, you have the thing. Thierry
