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 :)
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
