[Mono-devel-list] [PATCH] Field Layout Optimization

[Ben Maurer]

String.Intern Method --
If the value of str is already interned, the system's reference is
returned; otherwise, a new reference to a string with the value of str
is returned

String.IsInterned Method --
A String reference to str if it is in the common language runtime
"intern pool"; otherwise a null reference (Nothing in Visual Basic).

I am not sure what you mean by your first comment. String.IsInterned
("abc") will always return true (because abc is a literal in the code,
so it will be interned when the code runs.

>>> "Jonathan Gilbert" <2a5gjx302 at sneakemail.com> 03/15/04 08:12 AM >>>
I don't know about this particular detail for sure, but just thought I'd
point out that the string being interned does not imply that the
interned
copy will always be used. You might want to check string.IsInterned on
"abc"..

Speaking of which, why doesn't Java's string intern table have a way to
check if a string is interned without actually interning it? Just idle
thoughts...

Jonathan

At 08:38 PM 14/03/2004 -0500, you wrote:
>I am not so sure. For example, if you do something like:
>
>[MyAttribute ("abc")]
>
>And query for the attribute many times, the string is not interned. It
>is different any time.
>
>He might have been saying that all strings in the string heap are
>interned at load.
>
>-- Ben
>
>On Sun, 2004-03-14 at 18:48, Jonathan Pryor wrote:
>> On Sun, 2004-03-14 at 18:24, Ben Maurer wrote:
>> <snip/>
>> >       * Is it correct to load strings that are stored in literal
fields
>> >         as interned. The reason I did this was to ensure that we
dont
>> >         create a string on each access (which is incorrect).
However, I
>> >         am not sure if it shoudl be interned.
>> 
>> See: http://blogs.msdn.com/cbrumme/archive/2003/04/22/51371.aspx
>> 
>> .NET automatically interns all strings literals inside the assembly
when
>> the assembly is loaded.  The blog notes that: 
>> 
>>         This is expensive and -- in retrospect -- may have been a
>>         mistake.  In the future we might consider allowing individual
>>         assemblies to opt-in or opt-out.
>> 
>> For compatibility, we'll probably want to do the same, which is what
>> you're doing.  So this is the path of least resistance. :-)
>> 
>>  - Jon
>> 
>> 
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>_______________________________________________
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list