StringBuilder is obviously more efficient dealing with string concatenations than the old '+=' method... however, in dealing with relatively large string concatenations (ie, 20-30k), what are the performance differences (if any with something as trivial as this) between initializing a new instance of StringBuilder with a specified capacity vs. initializing a new instance without... (the final length is not fixed)
ie,
Performance differences between:
StringBuilder sb1 = new StringBuilder(30000);
and
StringBuilder sb1 = new StringBuilder();
Does this make a huge difference compared to '+='?
IF you are doing large string concatenations, definitely use the StringBuilder. There's no magic number per se, but on trivial concatentions, it's not a big deal. The main thing to remember is that strings are immutable, so 50 concatenations creates 50 string objects.
If you initialize the SB, you are better off if you go over the default size because it doesn't have to reallocate space, but this only comes into play if you exceed the default size. The performance differences really only are noticed between the two if you exceed the boundaries, so it's hard to say in absolute terms, it depends on the situation. If possible, try to initialize the capacity, but even if you don't, you'll be much better off than +=.
HTH,
Bill
"Kevin C" <kevin-calla...@sbcglobal.net> wrote in message
> StringBuilder is obviously more efficient dealing with string concatenations > than the old '+=' method... however, in dealing with relatively large string > concatenations (ie, 20-30k), what are the performance differences (if any > with something as trivial as this) between initializing a new instance of > StringBuilder with a specified capacity vs. initializing a new instance > without... (the final length is not fixed)
> ie,
> Performance differences between:
> StringBuilder sb1 = new StringBuilder(30000);
> and
> StringBuilder sb1 = new StringBuilder();
> Does this make a huge difference compared to '+='?
As a footnote though, which has the most negative (theorical?) effect on performance:
1) over initializing an instance, ie., setting capacity at 30,000 characters when you only need 20,000 or 2) under initialzing an instance, ie., setting capacity at 10,000 characters and having the StringBuilder class dynamically allocate more room for the additional 10,000 characters when you try to append 20,000.
-k
"William Ryan" <dotnetg...@comcast.nospam.net> wrote in message
> IF you are doing large string concatenations, definitely use the > StringBuilder. There's no magic number per se, but on trivial > concatentions, it's not a big deal. The main thing to remember is that > strings are immutable, so 50 concatenations creates 50 string objects.
> If you initialize the SB, you are better off if you go over the default size > because it doesn't have to reallocate space, but this only comes into play > if you exceed the default size. The performance differences really only are > noticed between the two if you exceed the boundaries, so it's hard to say in > absolute terms, it depends on the situation. If possible, try to initialize > the capacity, but even if you don't, you'll be much better off than +=.
> > StringBuilder is obviously more efficient dealing with string > concatenations > > than the old '+=' method... however, in dealing with relatively large > string > > concatenations (ie, 20-30k), what are the performance differences (if any > > with something as trivial as this) between initializing a new instance of > > StringBuilder with a specified capacity vs. initializing a new instance > > without... (the final length is not fixed)
> > ie,
> > Performance differences between:
> > StringBuilder sb1 = new StringBuilder(30000);
> > and
> > StringBuilder sb1 = new StringBuilder();
> > Does this make a huge difference compared to '+='?
> As a footnote though, which has the most negative (theorical?) effect > on performance:
> 1) over initializing an instance, ie., setting capacity at 30,000 > characters when you only need 20,000 > or > 2) under initialzing an instance, ie., setting capacity at 10,000 > characters and having the StringBuilder class dynamically allocate > more room for the additional 10,000 characters when you try to append > 20,000.
I would say that number 2 has the most negative impact. When you append characters that exceed the capacity of the StringBuilder, it must allocate memory large enough to hold the new string, copy the existing characters to it and then add the new characters. Whereas on number, the allocation is already do and it just has to append the new data.
Chris, StringBuilder does not keep the string data in a single continuous block of memory. What you described (allocating new chunk of memory, copying old data into it and appending the new data) is exactly how += for strings work. StringBuilder does not do that, it just allocates new memory to hold the new data and keeps both the old and the new, but not together. Of course calling ToString is going to finally add all the small chunks into one piece, so it only pays off if you do a lot (I've seen posts that roughly 5 was the magic number) of appending.
Jerry
"Chris Dunaway" <dunaw...@lunchmeatsbcglobal.net> wrote in message
> > As a footnote though, which has the most negative (theorical?) effect > > on performance:
> > 1) over initializing an instance, ie., setting capacity at 30,000 > > characters when you only need 20,000 > > or > > 2) under initialzing an instance, ie., setting capacity at 10,000 > > characters and having the StringBuilder class dynamically allocate > > more room for the additional 10,000 characters when you try to append > > 20,000.
> I would say that number 2 has the most negative impact. When you append > characters that exceed the capacity of the StringBuilder, it must allocate > memory large enough to hold the new string, copy the existing characters to > it and then add the new characters. Whereas on number, the allocation is > already do and it just has to append the new data.
Jerry III <jerry...@hotmail.com> wrote: > Chris, StringBuilder does not keep the string data in a single continuous > block of memory. What you described (allocating new chunk of memory, copying > old data into it and appending the new data) is exactly how += for strings > work. StringBuilder does not do that, it just allocates new memory to hold > the new data and keeps both the old and the new, but not together. Of course > calling ToString is going to finally add all the small chunks into one > piece, so it only pays off if you do a lot (I've seen posts that roughly 5 > was the magic number) of appending.
Do you have any evidence of this? This is certainly the first I've heard of it. As far as I'm aware, StringBuilder has a buffer, and once that is full, the buffer is copied and resized. That's the view that the rotor source suggests, too.
> Chris, StringBuilder does not keep the string data in a single continuous > block of memory. What you described (allocating new chunk of memory, copying > old data into it and appending the new data) is exactly how += for strings > work. StringBuilder does not do that, it just allocates new memory to hold > the new data and keeps both the old and the new, but not together. Of course > calling ToString is going to finally add all the small chunks into one > piece, so it only pays off if you do a lot (I've seen posts that roughly 5 > was the magic number) of appending.
> > > As a footnote though, which has the most negative (theorical?) effect > > > on performance:
> > > 1) over initializing an instance, ie., setting capacity at 30,000 > > > characters when you only need 20,000 > > > or > > > 2) under initialzing an instance, ie., setting capacity at 10,000 > > > characters and having the StringBuilder class dynamically allocate > > > more room for the additional 10,000 characters when you try to append > > > 20,000.
> > I would say that number 2 has the most negative impact. When you append > > characters that exceed the capacity of the StringBuilder, it must allocate > > memory large enough to hold the new string, copy the existing characters > to > > it and then add the new characters. Whereas on number, the allocation is > > already do and it just has to append the new data.
00004 // Copyright (c) 2002 Microsoft Corporation. All rights reserved. 00005 // 00017 ** Class: StringBuilder 00020 ** 00021 ** Purpose: A prototype implementation of the StringBuilder 00022 ** class. 00023 ** 00024 ** Date: December 8, 1997 00025 ** Last Updated: March 31, 1998 00026 ** 00028 namespace System.Text { 00029 using System.Text; 00030 using System.Runtime.Serialization; 00031 using System; 00032 using System.Runtime.CompilerServices; 00033 00052 [Serializable()] public sealed class StringBuilder {
Ok, I was not right, I guess I should decompile before I post something. I'm really disappointed, I thought the StringBuilder was a lot more efficient than this, I can just allocate large enough String and get a lot better performance (memory is pretty cheap).
Jerry
"Fergus Cooney" <filte...@tesco.net> wrote in message
