<
henrik.s.johansen@veloxit.no> 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 <
leves@elte.hu> 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 :)
>