String.Join vs. StringBuilder, which is faster?

[Bob]

I have a function that takes in a list of IDs (hundreds) as input parameter
and needs to pass the data to another step as a comma delimited string. The
source can easily create this list of IDs in a comma-delimited string or
string array. I don't want it to be a string because I want to overload
this function, and it's sister already uses a string input parameter. Now
if I define the function to take in a string array, it solves my overload
issue, but then I have to convert the array inside the function to a comma
delimited string using string.Join(). Alternatively, I can define the input
parameter as a StringBuilder (which just contains the comma delimited
string), and then do a sb.ToString() to get the string. Which would be a
better solution between using string array and then join vs. StringBuilder
and ToString?

I know if I don't overload at all, it would make the best sense from a
performance perspective, but code readability and maintenance become harder
as the two functions really do the very similar things.

Thanks
Bob

[Scott M.]

Re: String.Join vs. StringBuilder, which is faster?

Since strings are immutable (a new memory address is allocated each time
your alter the string), the StringBuilder is the way to go.


" Bob" <bobatkpmg@yaho o.com> wrote in message
news:OHarPwjAEH A.1548@TK2MSFTN GP12.phx.gbl...[color=blue]
> I have a function that takes in a list of IDs (hundreds) as input[/color]
parameter[color=blue]
> and needs to pass the data to another step as a comma delimited string.[/color]
The[color=blue]
> source can easily create this list of IDs in a comma-delimited string or
> string array. I don't want it to be a string because I want to overload
> this function, and it's sister already uses a string input parameter. Now
> if I define the function to take in a string array, it solves my overload
> issue, but then I have to convert the array inside the function to a comma
> delimited string using string.Join(). Alternatively, I can define the[/color]
input[color=blue]
> parameter as a StringBuilder (which just contains the comma delimited
> string), and then do a sb.ToString() to get the string. Which would be a
> better solution between using string array and then join vs. StringBuilder
> and ToString?
>
> I know if I don't overload at all, it would make the best sense from a
> performance perspective, but code readability and maintenance become[/color]
harder[color=blue]
> as the two functions really do the very similar things.
>
> Thanks
> Bob
>
>[/color]

[Jerry III]

Re: String.Join vs. StringBuilder, which is faster?

What does the fact that strings are immutable have to do with Bob's
question? String.Join is a static method of that class and creates a new
string object when called. Personally I would go with an array and Join, it
will be easier to understand (you're passing an array or a list of values)
and you won't have to loop to put all your values into a string builder.
That will never be faster than calling Join. Unless of course your input is
not an array of strings (you're saying a list of IDs, not sure about the
type there).

Jerry

"Scott M." <s-mar@BADSPAMsnet .net> wrote in message
news:ObyrgBlAEH A.2484@TK2MSFTN GP12.phx.gbl...[color=blue]
> Since strings are immutable (a new memory address is allocated each time
> your alter the string), the StringBuilder is the way to go.
>
>
> " Bob" <bobatkpmg@yaho o.com> wrote in message
> news:OHarPwjAEH A.1548@TK2MSFTN GP12.phx.gbl...[color=green]
> > I have a function that takes in a list of IDs (hundreds) as input[/color]
> parameter[color=green]
> > and needs to pass the data to another step as a comma delimited string.[/color]
> The[color=green]
> > source can easily create this list of IDs in a comma-delimited string or
> > string array. I don't want it to be a string because I want to overload
> > this function, and it's sister already uses a string input parameter.[/color][/color]
Now[color=blue][color=green]
> > if I define the function to take in a string array, it solves my[/color][/color]
overload[color=blue][color=green]
> > issue, but then I have to convert the array inside the function to a[/color][/color]
comma[color=blue][color=green]
> > delimited string using string.Join(). Alternatively, I can define the[/color]
> input[color=green]
> > parameter as a StringBuilder (which just contains the comma delimited
> > string), and then do a sb.ToString() to get the string. Which would be[/color][/color]
a[color=blue][color=green]
> > better solution between using string array and then join vs.[/color][/color]
StringBuilder[color=blue][color=green]
> > and ToString?
> >
> > I know if I don't overload at all, it would make the best sense from a
> > performance perspective, but code readability and maintenance become[/color]
> harder[color=green]
> > as the two functions really do the very similar things.
> >
> > Thanks
> > Bob
> >
> >[/color]
>
>[/color]

[Justin Rogers]

Re: String.Join vs. StringBuilder, which is faster?

String.Join is implemented internally by the run-time. It is serviced by the
ConcatenateJoin HelperArray method which turns out to be extremely fast at
creating the final string as opposed to the slightly slower
StringBuilder.A ppend. If you have an array of strings, I would recommend using
that with String.Join over StringBuilder.A ppend since String.Join is going to be
quite a bit faster.

using System;
using System.Text;

public class JoinVsBuilder {
private static string[] strings = new string[0];

private static void Main(string[] args) {
int count = int.Parse(args[0]);

strings = new string[count];
for(int i = 0; i < count; i++) {
strings[i] = i.ToString();
}

DateTime start, end;

start = DateTime.Now;
string newStr = string.Join("fo o", strings);
end = DateTime.Now;
Console.WriteLi ne("String::Joi n timing is {0}", end-start);

StringBuilder sb = new StringBuilder() ;
start = DateTime.Now;

// Faster than worrying about when to append the connector
sb.Append(strin gs[0]);
for(int i = 1; i < strings.Length; i++) {
sb.Append("foo" );
sb.Append(strin gs[i]);
}
string newStr2 = sb.ToString();
end = DateTime.Now;
Console.WriteLi ne("StringBuild er::Append timing is {0}", end-start);
}
}

C:\Projects\CSh arp\Samples\Joi nVsBuilder>Join VsBuilder.exe 1000000
String::Join timing is 00:00:00.460662 4
StringBuilder:: Append timing is 00:00:02.914190 4


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Jerry III" <jerryiii@hotma il.com> wrote in message
news:uTUX%230mA EHA.3804@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> What does the fact that strings are immutable have to do with Bob's
> question? String.Join is a static method of that class and creates a new
> string object when called. Personally I would go with an array and Join, it
> will be easier to understand (you're passing an array or a list of values)
> and you won't have to loop to put all your values into a string builder.
> That will never be faster than calling Join. Unless of course your input is
> not an array of strings (you're saying a list of IDs, not sure about the
> type there).
>
> Jerry
>
> "Scott M." <s-mar@BADSPAMsnet .net> wrote in message
> news:ObyrgBlAEH A.2484@TK2MSFTN GP12.phx.gbl...[color=green]
> > Since strings are immutable (a new memory address is allocated each time
> > your alter the string), the StringBuilder is the way to go.
> >
> >
> > " Bob" <bobatkpmg@yaho o.com> wrote in message
> > news:OHarPwjAEH A.1548@TK2MSFTN GP12.phx.gbl...[color=darkred]
> > > I have a function that takes in a list of IDs (hundreds) as input[/color]
> > parameter[color=darkred]
> > > and needs to pass the data to another step as a comma delimited string.[/color]
> > The[color=darkred]
> > > source can easily create this list of IDs in a comma-delimited string or
> > > string array. I don't want it to be a string because I want to overload
> > > this function, and it's sister already uses a string input parameter.[/color][/color]
> Now[color=green][color=darkred]
> > > if I define the function to take in a string array, it solves my[/color][/color]
> overload[color=green][color=darkred]
> > > issue, but then I have to convert the array inside the function to a[/color][/color]
> comma[color=green][color=darkred]
> > > delimited string using string.Join(). Alternatively, I can define the[/color]
> > input[color=darkred]
> > > parameter as a StringBuilder (which just contains the comma delimited
> > > string), and then do a sb.ToString() to get the string. Which would be[/color][/color]
> a[color=green][color=darkred]
> > > better solution between using string array and then join vs.[/color][/color]
> StringBuilder[color=green][color=darkred]
> > > and ToString?
> > >
> > > I know if I don't overload at all, it would make the best sense from a
> > > performance perspective, but code readability and maintenance become[/color]
> > harder[color=darkred]
> > > as the two functions really do the very similar things.
> > >
> > > Thanks
> > > Bob
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Scott M.]

Re: String.Join vs. StringBuilder, which is faster?


"Jerry III" <jerryiii@hotma il.com> wrote in message
news:uTUX%230mA EHA.3804@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> What does the fact that strings are immutable have to do with Bob's
> question? String.Join is a static method of that class and creates a new
> string object when called. Personally I would go with an array and Join,[/color]
it[color=blue]
> will be easier to understand (you're passing an array or a list of values)
> and you won't have to loop to put all your values into a string builder.
> That will never be faster than calling Join. Unless of course your input[/color]
is[color=blue]
> not an array of strings (you're saying a list of IDs, not sure about the
> type there).[/color]


Because, as you said "String.Joi n is a static method of that class and
creates a new string object when called.". Each time its called, it will
create a new string, and thus a new spot on the heap. A StringBuilder will
only need one memory address and for this reason, usually performs better.
[color=blue]
>
> Jerry
>
> "Scott M." <s-mar@BADSPAMsnet .net> wrote in message
> news:ObyrgBlAEH A.2484@TK2MSFTN GP12.phx.gbl...[color=green]
> > Since strings are immutable (a new memory address is allocated each time
> > your alter the string), the StringBuilder is the way to go.
> >
> >
> > " Bob" <bobatkpmg@yaho o.com> wrote in message
> > news:OHarPwjAEH A.1548@TK2MSFTN GP12.phx.gbl...[color=darkred]
> > > I have a function that takes in a list of IDs (hundreds) as input[/color]
> > parameter[color=darkred]
> > > and needs to pass the data to another step as a comma delimited[/color][/color][/color]
string.[color=blue][color=green]
> > The[color=darkred]
> > > source can easily create this list of IDs in a comma-delimited string[/color][/color][/color]
or[color=blue][color=green][color=darkred]
> > > string array. I don't want it to be a string because I want to[/color][/color][/color]
overload[color=blue][color=green][color=darkred]
> > > this function, and it's sister already uses a string input parameter.[/color][/color]
> Now[color=green][color=darkred]
> > > if I define the function to take in a string array, it solves my[/color][/color]
> overload[color=green][color=darkred]
> > > issue, but then I have to convert the array inside the function to a[/color][/color]
> comma[color=green][color=darkred]
> > > delimited string using string.Join(). Alternatively, I can define the[/color]
> > input[color=darkred]
> > > parameter as a StringBuilder (which just contains the comma delimited
> > > string), and then do a sb.ToString() to get the string. Which would[/color][/color][/color]
be[color=blue]
> a[color=green][color=darkred]
> > > better solution between using string array and then join vs.[/color][/color]
> StringBuilder[color=green][color=darkred]
> > > and ToString?
> > >
> > > I know if I don't overload at all, it would make the best sense from a
> > > performance perspective, but code readability and maintenance become[/color]
> > harder[color=darkred]
> > > as the two functions really do the very similar things.
> > >
> > > Thanks
> > > Bob
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: String.Join vs. StringBuilder, which is faster?

Scott M. <s-mar@BADSPAMsnet .net> wrote:[color=blue]
> Because, as you said "String.Joi n is a static method of that class and
> creates a new string object when called.". Each time its called, it will
> create a new string, and thus a new spot on the heap. A StringBuilder will
> only need one memory address and for this reason, usually performs better.[/color]

No, because here only one call to String.Join is needed. A
StringBuilder is better than manually creating lots of new strings, but
that doesn't happen in String.Join.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Daniel Billingsley]

Re: String.Join vs. StringBuilder, which is faster?

Yes, this is a perfect example where StringBuilder at the very best provides
no advantage, and most likely is at a strong disadvantage. Just because
Microsoft and others have preached that it should always be used whenever
there's any kind of concatenation, don't believe it.

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ab293 1354531f5098a32 1@msnews.micros oft.com...[color=blue]
> Scott M. <s-mar@BADSPAMsnet .net> wrote:[color=green]
> > Because, as you said "String.Joi n is a static method of that class and
> > creates a new string object when called.". Each time its called, it[/color][/color]
will[color=blue][color=green]
> > create a new string, and thus a new spot on the heap. A StringBuilder[/color][/color]
will[color=blue][color=green]
> > only need one memory address and for this reason, usually performs[/color][/color]
better.[color=blue]
>
> No, because here only one call to String.Join is needed. A
> StringBuilder is better than manually creating lots of new strings, but
> that doesn't happen in String.Join.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Brad Williams]

Re: String.Join vs. StringBuilder, which is faster?

I recreated your test, tweaking it so that there is no connector (thus only
one Append in the loop). I consistently get Join being 2 to 2-1/2 times
faster than a series of SB Appends.

[Jon Skeet [C# MVP]]

Re: String.Join vs. StringBuilder, which is faster?

Daniel Billingsley <dbillingsley@N O.durcon.SPAAMM .com> wrote:[color=blue]
> Yes, this is a perfect example where StringBuilder at the very best provides
> no advantage, and most likely is at a strong disadvantage. Just because
> Microsoft and others have preached that it should always be used whenever
> there's any kind of concatenation, don't believe it.[/color]

I don't think they *have* actually preached that - people who've
understood *part* of why it's worth using StringBuilder but not all of
it have preached it. I don't think MS put particularly blanket
recommendations out. Let me know where they are and I'll complain about
them, if they do exist :)

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Alvin Bruney [MVP]]

Re: String.Join vs. StringBuilder, which is faster?

These issues with stringbuilder performance have a strange ring of
familiartiy eh skeet?

--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...

http://tinyurl.com/3he3b

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ab2b6 37e0ba9da098a32 6@msnews.micros oft.com...[color=blue]
> Daniel Billingsley <dbillingsley@N O.durcon.SPAAMM .com> wrote:[color=green]
> > Yes, this is a perfect example where StringBuilder at the very best[/color][/color]
provides[color=blue][color=green]
> > no advantage, and most likely is at a strong disadvantage. Just because
> > Microsoft and others have preached that it should always be used[/color][/color]
whenever[color=blue][color=green]
> > there's any kind of concatenation, don't believe it.[/color]
>
> I don't think they *have* actually preached that - people who've
> understood *part* of why it's worth using StringBuilder but not all of
> it have preached it. I don't think MS put particularly blanket
> recommendations out. Let me know where they are and I'll complain about
> them, if they do exist :)
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Justin Rogers]

Re: String.Join vs. StringBuilder, which is faster?

Figured I'd post up my latest testing. The StringBuilder really isn't as bad as
the original test showed.
What is missing is that behind the scenes String::Join is computing an optimally
sized memory array,
while the StringBuilder is constantly expanding it's own. If you use capacity
planning then the
StringBuilder is only about 25% slower than the String::Join. In addition there
are some string interning
problems that tend to affect performance quite a bit that I've been able to
compute out of my analysis.

Original performance testing post:

http://weblogs.asp.net/justin_rogers/archive/2004/03/04/84306.aspx

Revised performance testing post:

http://weblogs.asp.net/justin_rogers/archive/2004/03/05/84986.aspx

I definitely understand why Microsoft recommends the use of StringBuilder. Most
developers tend to
subscribe to a form of lazy concatenation rather than preparing their data for a
more specialized method.
Many algorithms also favor lazy concatenation rather than preparing data up
front (ASP .NET is probably
the number one subscribe since their entire system is based on lazy
concatenation). If you do some capacity
planning or limit the number of times the builder will be resized you can get
much better performance from
the StringBuilder than I'm sure most people are getting because they don't take
performance very seriously
or don't know what it takes to squeeze performance out of the StringBuilder.

--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
news:%23kYyS%23 uAEHA.2036@TK2M SFTNGP12.phx.gb l...[color=blue]
> These issues with stringbuilder performance have a strange ring of
> familiartiy eh skeet?
>
> --
> Regards,
> Alvin Bruney [ASP.NET MVP]
> Got tidbits? Get it here...
> http://tinyurl.com/3he3b
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1ab2b6 37e0ba9da098a32 6@msnews.micros oft.com...[color=green]
> > Daniel Billingsley <dbillingsley@N O.durcon.SPAAMM .com> wrote:[color=darkred]
> > > Yes, this is a perfect example where StringBuilder at the very best[/color][/color]
> provides[color=green][color=darkred]
> > > no advantage, and most likely is at a strong disadvantage. Just because
> > > Microsoft and others have preached that it should always be used[/color][/color]
> whenever[color=green][color=darkred]
> > > there's any kind of concatenation, don't believe it.[/color]
> >
> > I don't think they *have* actually preached that - people who've
> > understood *part* of why it's worth using StringBuilder but not all of
> > it have preached it. I don't think MS put particularly blanket
> > recommendations out. Let me know where they are and I'll complain about
> > them, if they do exist :)
> >
> > --
> > Jon Skeet - <skeet@pobox.co m>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: String.Join vs. StringBuilder, which is faster?

Justin Rogers <Justin@games4d otnet.com> wrote:[color=blue]
> In addition there
> are some string interning problems that tend to affect performance quite a bit
> that I've been able to compute out of my analysis.[/color]

I don't understand this point. In the code that I've seen, there isn't
any interning going on apart from the interning "foo" which only
happens once. Nothing should be interning each of the bits which ends
up being joined.

Far more likely, IMO, is that you've got garbage collection occurring -
but that's an entirely different thing from string interning.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Justin Rogers]

Re: String.Join vs. StringBuilder, which is faster?

All strings are present in a global string table. This is how you ensure
immutability.
To compact the string table and prevent instances where the same string is
present
in memory more than once they do a scan to make sure the string doesn't already
exist (using a string hash I believe). If it does then your string reference
simply points
to the already allocated string table slot. Since we are building the same
exact string
many times, the second and any subsequent time we build the same string we incur
a performance hit as the string table is searched. Since the strings in the
example
are very large it takes a while to do the comparison and find the string (aka
computing
the hash).

There is no garbage collection in the example if you run it using the parameters
I
pointed out in the article. At least not with a sufficient amount of memory.
The string
allocations themselves only take up say:

3 * 1million + 7 * 1million, or approximately 10 million characters.

If the sample is changed to ensure that the strings are referenced throughout
the operation
of the program and then used at the end of the program, it makes no changes to
the
performance characteristics . No GC is happening.


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ab390 1178d6d28698a32 d@msnews.micros oft.com...[color=blue]
> Justin Rogers <Justin@games4d otnet.com> wrote:[color=green]
> > In addition there
> > are some string interning problems that tend to affect performance quite a[/color][/color]
bit[color=blue][color=green]
> > that I've been able to compute out of my analysis.[/color]
>
> I don't understand this point. In the code that I've seen, there isn't
> any interning going on apart from the interning "foo" which only
> happens once. Nothing should be interning each of the bits which ends
> up being joined.
>
> Far more likely, IMO, is that you've got garbage collection occurring -
> but that's an entirely different thing from string interning.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: String.Join vs. StringBuilder, which is faster?

Justin,
You just described Interning, however as Jon stated Interning is not
involved here!

Try the following:

char c1 = 'a', c2 = 'b';

string s1 = "ab", s2 = string.Concat(c 1, c2);

System.Diagnost ics.Debug.Write Line(string.Equ als(s1, s2), "s1 == s2");
System.Diagnost ics.Debug.Write Line(string.Ref erenceEquals(s1 , s2), "s1
is s2");

string.Equals is true as they contain the same characters, however
string.Referenc eEquals is false as they were not interned!

Hope this helps
Jay

"Justin Rogers" <Justin@games4d otnet.com> wrote in message
news:OilFg03AEH A.576@TK2MSFTNG P11.phx.gbl...[color=blue]
> All strings are present in a global string table. This is how you ensure
> immutability.
> To compact the string table and prevent instances where the same string is
> present
> in memory more than once they do a scan to make sure the string doesn't[/color]
already[color=blue]
> exist (using a string hash I believe). If it does then your string[/color]
reference[color=blue]
> simply points
> to the already allocated string table slot. Since we are building the[/color]
same[color=blue]
> exact string
> many times, the second and any subsequent time we build the same string we[/color]
incur[color=blue]
> a performance hit as the string table is searched. Since the strings in[/color]
the[color=blue]
> example
> are very large it takes a while to do the comparison and find the string[/color]
(aka[color=blue]
> computing
> the hash).
>
> There is no garbage collection in the example if you run it using the[/color]
parameters[color=blue]
> I
> pointed out in the article. At least not with a sufficient amount of[/color]
memory.[color=blue]
> The string
> allocations themselves only take up say:
>
> 3 * 1million + 7 * 1million, or approximately 10 million characters.
>
> If the sample is changed to ensure that the strings are referenced[/color]
throughout[color=blue]
> the operation
> of the program and then used at the end of the program, it makes no[/color]
changes to[color=blue]
> the
> performance characteristics . No GC is happening.
>
>
> --
> Justin Rogers
> DigiTec Web Consultants, LLC.
> Blog: http://weblogs.asp.net/justin_rogers
>
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1ab390 1178d6d28698a32 d@msnews.micros oft.com...[color=green]
> > Justin Rogers <Justin@games4d otnet.com> wrote:[color=darkred]
> > > In addition there
> > > are some string interning problems that tend to affect performance[/color][/color][/color]
quite a[color=blue]
> bit[color=green][color=darkred]
> > > that I've been able to compute out of my analysis.[/color]
> >
> > I don't understand this point. In the code that I've seen, there isn't
> > any interning going on apart from the interning "foo" which only
> > happens once. Nothing should be interning each of the bits which ends
> > up being joined.
> >
> > Far more likely, IMO, is that you've got garbage collection occurring -
> > but that's an entirely different thing from string interning.
> >
> > --
> > Jon Skeet - <skeet@pobox.co m>
> > http://www.pobox.com/~skeet
> > If replying to the group, please do not mail me too[/color]
>
>[/color]

[Jon Skeet [C# MVP]]

Re: String.Join vs. StringBuilder, which is faster?

Justin Rogers <Justin@games4d otnet.com> wrote:[color=blue]
> All strings are present in a global string table. This is how you ensure
> immutability.[/color]

No they're not. Only strings which are interned do this. It happens
automatically for strings literals, and you can ask other strings to be
interned. It doesn't happen automatically for *all* strings.

<snip>
[color=blue]
> There is no garbage collection in the example if you run it using the parameters
> I pointed out in the article.[/color]

Yes there is.
[color=blue]
> At least not with a sufficient amount of memory.
> The string allocations themselves only take up say:
>
> 3 * 1million + 7 * 1million, or approximately 10 million characters.[/color]

And that's far more than the size of generation 0 in the heap - so
garbage collection *will* take place. You can see this with the
performance monitor if you want.
[color=blue]
> If the sample is changed to ensure that the strings are referenced throughout
> the operation of the program and then used at the end of the program, it makes no
> changes to the performance characteristics . No GC is happening.[/color]

Well there certainly isn't any interning happening...

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too