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. 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
