string sharing (possible bug?)

glenn krasner at objectshare.com
Thu Dec 10 18:45:09 UTC 1998


At 02:31 PM 12/10/98 +0000, Ted Wrinch wrote:
>Hi,
>
>I though I'd add my two cents worth to this growing thread. As far as I
recall,
>an expresion like 'Hello' == 'Hello' used to anwser 'false' in the old
Digitalk
>Smalltalk wherever it was encountered: ie a new object was allocated by the
>compiler for every string literal. I actually thought this was supposed to be
>the distinction between Strings and Symbols - the same Symbols are guaranteed
>to share the same memory. 
>The Squeak/Visual Works idea that the same string literals share memory
within 
>methods but not elsewhere seems unneccessarily confusing.

Yes, that's why this is *not* how VisualWorks does it, only Squeak.

>Also, Glen's observation:
>
>>And, for example in the case of our window builder, suffer a large
>>performance penalty every time you open a window. And that penalty would be
>>paid by everyone just so that the few people who accidentally store into a
>>literal array or string would have a better time of it. That's not the
>>tradeoff we decided to make, and I suspect that this would also be a worse
>>choice for Squeak.
>
>seems a little stange. I thought space for literals was allocated at compile
>time so the performance penalty he reasonably complains about would occur at
>window design time. At run-time the memory would already have been allocated
>and should not impact window opening times. Using Symbols would be an
>alternative to Strings to save memory but would presumably adversely
affect the
>size of the symbol table.

I was arguing against the proposal for run-time allocation of string and
array literal structures and for keeping compile-time literal instantiation
as is done in Squeak, VW, VSE, VA and as you describe.  In that context, is
it less strange?

glenn





More information about the Squeak-dev mailing list