[Mono-devel-list] [PATCH] Field Layout Optimization
2a5gjx302 at sneakemail.com
Tue Mar 16 22:38:01 EST 2004
public class MainClass
static void Main()
string a = "a";
string b = "bc";
Console.WriteLine(string.IsInterned(a + b));
At 09:56 AM 15/03/2004 -0500, you wrote:
>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
>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
>copy will always be used. You might want to check string.IsInterned on
>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
>At 08:38 PM 14/03/2004 -0500, you wrote:
>>I am not so sure. For example, if you do something like:
>>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.
>>On Sun, 2004-03-14 at 18:48, Jonathan Pryor wrote:
>>> On Sun, 2004-03-14 at 18:24, Ben Maurer wrote:
>>> > * Is it correct to load strings that are stored in literal
>>> > as interned. The reason I did this was to ensure that we
>>> > create a string on each access (which is incorrect).
>>> > 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
>>> 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
>>Mono-devel-list mailing list
>>Mono-devel-list at lists.ximian.com
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list