On Mon, Sep 27, 2010 at 3:31 PM, Igor Stasenko <[email protected]> wrote:
> On 28 September 2010 00:29, Henrik Sperre Johansen > <[email protected]> wrote: > > On 27.09.2010 23:05, Levente Uzonyi wrote: > >> > >> On Mon, 27 Sep 2010, Igor Stasenko wrote: > >> > >>> On 27 September 2010 22:10, Levente Uzonyi <[email protected]> wrote: > >>> On Mon, 27 Sep 2010, Johan Brichau wrote: > >>> > >>>> > >>>> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: > >>>> > >>>>> "Works fine" is a value judgment that can cut both ways: one could > also > >>>>> argue that VW lacks a useful optimization of literals. Non-literal > >>>>> strings > >>>>> should do what you want. > >>>> > >>>> I wonder how useful the optimization is, actually. > >>>> Probably not many (if any) methods will use the same literal multiple > >>>> times and count on the compiler to optimize them into the same > literal. > >>> > >>> I think this is from the 80's or 90's where this could save some > memory. > >>> According to my calculations in Squeak 4.2 with some extra packages > >>> loaded > >>> it saves at least 36591 bytes (object size + 1 slot in the literal > >>> array), > >>> which is only 0.79 bytes / method. > >>> > >> > >> Well, you can save a bit more, if you scan a whole image literals and > >> unify them. > >> This could be userful for tidying up the image size. > >> > >> > >> Probably yes, but that's not the point I guess. I just wanted to show > that > >> the current method doesn't really save much. Unifying the literals in > the > >> image is dangerous, because literal strings are not immutable (and they > >> shouldn't be IMHO). So that could lead to random errors if a method is > >> modifying a shared string literal. > >> > >> > >> Levente > >> > > ByteString allInstances asBag sortedCounts > > Guess who the biggest waster in Core12147 is, at nearly 60KB duplicate > > strings for three top 5 finishes? :) > > > > Starting in VW post the immutable string literals change that was done > > there, I don't really mind it. > > Personally, I feel the gains are too low to even justify it for space > > efficiency reasons though, and the immutable string literal discussion, > > which would be needed, is a big one. > > > > I vaguely remember reading something like that in CompiledMethods, access > is > > faster for literal slots 1-n, where n is a rather low number. > > Even if that would turn out to be true, I doubt it warrants the compiler > > optimizations for equivalent literal strings anymore though. > > Spacewise you've at least already debunked that it's needed :) > > > > Well, unifying for space is one thing. > Another is search for a literal in image. It could be much quicker if > all literals are unified. > Arguably, but much of the time would go in the search of methods for literals rather than the faster comparisons between literals. However, the notion that this would save space is suspect. To implement literal pooling you either slow-down compilation *a lot* by searching for literals amongst all methods (an implicit pool) or you maintain an explicit pool and likely end up _not saving any space_ since the space occupied by the pool is more-or-less equal to to the space saved by pooling since you'll likely find literals are shared approximately once. We've been-there-done-that with VisualWorks trying to pool the bytecodes in methods and abandoned the idea because there was no net space saving. So you need to quantify the degree of sharing you see in a typical dev image and see whether average sharing is significantly greater than 1. Its not an invitation to do it, just to consider options which opening > for us, if we do that :) > > > Cheers, > > Henry > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
