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... 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: 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/ 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 ;) > I let Martin and Mariano give the details :). > > On Fri, Dec 5, 2014 at 9:28 AM, Thierry Goubier <thierry.goub...@gmail.com > > wrote: > >> >> >> 2014-12-05 8:35 GMT+01:00 Max Leske <maxle...@gmail.com>: >> >>> >>> > On 05 Dec 2014, at 08:02, Norbert Hartl <norb...@hartl.name> wrote: >>> > >>> > >>> > >>> > >>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier < >>> thierry.goub...@gmail.com>: >>> >> >>> >> Hi all, >>> >> >>> >> I'm just wondering. >>> >> >>> >> Would it work to have a package format based on Fuel? >>> >> >>> > I doubt it would work cross platform. I don't know how fuel serializes >>> WideString, LargePositiveInteger, BoxedFloat64. These differ between >>> smalltalk platforms. The source as string solves that. Strings are written >>> as unicode string and numbers as certain number format etc. >>> >>> True. Cross dialect loading isn’t something we encourage to do with Fuel. >>> >>> @Thierry >>> You said something about partial loading: that will never be possible >>> with Fuel because of its pickle format. To select any partial graph you >>> have to first read the entire file and rebuild the graph first (ok, you >>> don’t strictly have to build the graph but you still need to read the >>> entire file). >>> >> >> Hum. I was thinking of partial loading at the application level, not at >> the marshalling level. >> >> The process of cutting out Monticello packages versions ancestry in Pharo >> releases come to mind as a ... how should I say that ... We can/should do >> better (additionally, because if the mcz isn't available somewhere, having >> its ref its useless). >> >> Thierry >> >> >>> >>> > >>> > Norbert >>> > >>> >> Would that make loading faster? >>> >> >>> >> Does it already exist? >>> >> >>> >> Thanks, >>> >> >>> >> Thierry >>> > >>> >>> >>> >> > -- Mariano http://marianopeck.wordpress.com
