On Fri, Dec 5, 2014 at 6:55 AM, Guillermo Polito <guillermopolito@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 fuelThis 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... 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.�
�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.
�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.�
Tanker was originally called "FuelPackageLoader" and was then renamed. Some useful links with details:
�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 ;)