[Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sat Oct 2 03:41:53 EDT 2010

2010/10/2 Igor Stasenko <siguctua at gmail.com>:
>>> I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger,
>>> if
>>> I will improve performance since I don't need to fetch a .sources file.
>>> what would be awesome is if we can have both, this is: for the dev image,
>>> I
>>> would like to have the sources in the image, but not for PharoCore. Or
>>> maybe
>>> also in PharoCore but to be sure to be able to remove them, and use
>>> .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction
>>> or
>>> similar.
>>> thoughts?
>> You'd also lose versioning, since a trailer can only hold one version of the
>> source code. Btw, do you really have a performance issue reading the
>> sources? With Cog and Squeak 4.2, I get:
>> methods := CompiledMethod allInstances shuffle.
>> [ methods do: #getSource ] timeToRun "===> 1162"
>> So it takes ~25 microseconds to fetch the source of a method on average.
>> That's more than 39000 methods per second. It should be enough IMHO.
> Well, you can always change the trailer(s) to hold additional info.
> As i told before, we need a source management layer, which allows
> multiple different implementations,
> then its not quite important how/where we persisting sources, since we
> could switch between them,
> or use different source manager on a per-method basis.

Sure, I was thinking of it, but removed methods will hardly have a
trailer for example.
And reconstructing the history will be difficult too.


>> Levente
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

More information about the Pharo-dev mailing list