Quick Question:
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 '+='?
Cheers,
-k
37  4633 
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" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
bill,
thanks for the quick reply -- that makes sense.
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" <do********@comcast.nospam.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
"Kevin C" <ke************@sbcglobal.net> wrote in
news:LB*****************@newssvr27.news.prodigy.co m:
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
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" <du******@lunchmeatsbcglobal.net> wrote in message
news:Xn**********************************@207.46.2 48.16... "Kevin C" <ke************@sbcglobal.net> wrote in
news:LB*****************@newssvr27.news.prodigy.co m:
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
Jerry III <je******@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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Are you sure about that? A quick look at the StringBuilder class with
Anakrino and ildasm seems to show a new allocation and copy of the old
buffer.
"Jerry III" <je******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... 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" <du******@lunchmeatsbcglobal.net> wrote in message
news:Xn**********************************@207.46.2 48.16... "Kevin C" <ke************@sbcglobal.net> wrote in
news:LB*****************@newssvr27.news.prodigy.co m:
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
Hi Folks,
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 {
Full details at: http://dotnet.di.unipi.it/Content/ss...ngbuilder_8cs-
source.html
Regards,
Fergus
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" <fi******@tesco.net> wrote in message
news:u$**************@TK2MSFTNGP11.phx.gbl... Hi Folks,
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 {
Full details at:
http://dotnet.di.unipi.it/Content/ss...ngbuilder_8cs- source.html
Regards,
Fergus
Jerry III <je******@hotmail.com> wrote: 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).
What do you mean by "just allocate large enough String"?
Could you give an example of concatenating many strings together in a
loop and allowing parts of the concatenation to be removed or replaced
where your code gives better performance than StringBuilder?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Jerry,
You're right - and shouldn't be disappointed - StringBuilder <is> a lot
more efficient (time-wise, at least). Because it doubles when it needs to
grow, the number of 'grows' is pretty minimal. Of course, if you have a 10MB
string to which you want to add a single character, it'll grab another 20MB to
do it!!
The trouble with allocating a huge string is that as soon as you do
anything with it, you'll get a new totally different string - with that
massive one left for the GC. Ouch! You can't insert <into> a string, but
that's exactly what the StringBuilder is designed for.
Regards,
Fergus
ps. Jon is a need-for-truth man. Getting things wrong and having JS correct
you happens to me too, lol - and then I know more than I did. So, too, does
anyone else who had the same misconceptions. :-)
Fergus Cooney <fi******@tesco.net> wrote: ps. Jon is a need-for-truth man. Getting things wrong and having JS correct
you happens to me too, lol - and then I know more than I did. So, too, does
anyone else who had the same misconceptions. :-)
Fortunately it also happens to me too. I'd far rather post my beliefs
and have them thoroughly disproved (as has happened several times) than
shut up and have people believe that I know what's going on when I
don't.
Basically, what I'm trying to say is that being wrong is something that
happens to absolutely everyone, and that I mean no disrespect when I
correct/question someone.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I was talking about concatenating, I have yet to come across code that uses
StringBuilder (or StringBuffer in Java) to replace or remove parts of the
string. In those cases using existing code (those two classes) will be
efficient, but if you only do concatenating you are still far better off
making a guess of how long will your string be and preallocating the memory
yourself - i.e. telling StringBuilder how much it should allocate in the
constructor.
Personally I think it might be worth giving up some speed in ToString and
removing/replacing in order to make appending a lot faster. And if you're
going to ask - no, I don't have any code that proves any of this :(
Jerry
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jerry III <je******@hotmail.com> wrote: 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).
What do you mean by "just allocate large enough String"?
Could you give an example of concatenating many strings together in a
loop and allowing parts of the concatenation to be removed or replaced
where your code gives better performance than StringBuilder?
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jerry III <je******@hotmail.com> wrote: I was talking about concatenating, I have yet to come across code that uses
StringBuilder (or StringBuffer in Java) to replace or remove parts of the
string.
Ah - I have, although I agree that the most common case is just
appending.
In those cases using existing code (those two classes) will be
efficient, but if you only do concatenating you are still far better off
making a guess of how long will your string be and preallocating the memory
yourself - i.e. telling StringBuilder how much it should allocate in the
constructor.
Personally I think it might be worth giving up some speed in ToString and
removing/replacing in order to make appending a lot faster. And if you're
going to ask - no, I don't have any code that proves any of this :(
If you're never going to remove/replace/insert, you probably could
indeed improve the performance. Having said that, a quick attempt to do
so in an obvious way failed. One of the advantages of StringBuilder is
that if you don't need to expand the string in the end, the result of
ToString is just *there* with no further effort.
I might investigate this further though - see if I can come up with
something which beats StringBuilder in the simple case.
I suspect that StringBuilder is rarely the bottleneck in apps, however
- whereas simple repeated string concatenation in a loop easily could
be.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I'll throw in my 2-cents worth. After reading about the efficiency of
StringBuilder I changed a lot of my code in order to eliminate the large
number of string concats. However, when I ran the profiler and other timing
tests I found that my code was actually slower with StringBuilder. I didn't
investigate further (because the simple solution was to go back to strings),
but my experience indicates that there are definitely situations where the
overhead of StringBuilder is greater than the efficiencies. BTW, I thought I
was a perfect candidate for using StringBuilder because my code does a LOT
of string concats. Take that for what it's worth.
Dave
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jerry III <je******@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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Mountain Bikn' Guy <vc@attbi.com> wrote: I'll throw in my 2-cents worth. After reading about the efficiency of
StringBuilder I changed a lot of my code in order to eliminate the large
number of string concats. However, when I ran the profiler and other timing
tests I found that my code was actually slower with StringBuilder. I didn't
investigate further (because the simple solution was to go back to strings),
but my experience indicates that there are definitely situations where the
overhead of StringBuilder is greater than the efficiencies. BTW, I thought I
was a perfect candidate for using StringBuilder because my code does a LOT
of string concats. Take that for what it's worth.
Unfortunately, without more code, it's not worth a lot :(
If you *are* doing a lot of string concatenations, and you don't need
the results as strings between operations, it really *should* have been
quicker using StringBuilder.
If you ever get a separable bit of code which is demonstrating that
behaviour, I'd be interested to see it.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
I think the issue here is doing a lot of concatenations as opposed to doing
a lot of concatenations into one resulting string. Replacing a single string
add with a string builder will definitely make your app slower, no matter
how many times you actually add strings in your app, the advantage of
StringBuilder shows up when you're adding a lot of strings into one result
you use at the end.
Jerry
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Mountain Bikn' Guy <vc@attbi.com> wrote: I'll throw in my 2-cents worth. After reading about the efficiency of
StringBuilder I changed a lot of my code in order to eliminate the large
number of string concats. However, when I ran the profiler and other
timing tests I found that my code was actually slower with StringBuilder. I
didn't investigate further (because the simple solution was to go back to
strings), but my experience indicates that there are definitely situations where
the overhead of StringBuilder is greater than the efficiencies. BTW, I
thought I was a perfect candidate for using StringBuilder because my code does a
LOT of string concats. Take that for what it's worth.
Unfortunately, without more code, it's not worth a lot :(
If you *are* doing a lot of string concatenations, and you don't need
the results as strings between operations, it really *should* have been
quicker using StringBuilder.
If you ever get a separable bit of code which is demonstrating that
behaviour, I'd be interested to see it.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Jon,
I've seen your posts and know a bit about your mind. I've seen your site
and know a bit about your heart. 'Tis good for I respect you in both ways. ;-)
Regards,
Fergus
Jerry III <je******@hotmail.com> wrote: I think the issue here is doing a lot of concatenations as opposed to doing
a lot of concatenations into one resulting string. Replacing a single string
add with a string builder will definitely make your app slower, no matter
how many times you actually add strings in your app, the advantage of
StringBuilder shows up when you're adding a lot of strings into one result
you use at the end.
Yup, that's absolutely right. Note that I think the threshold for doing
this in Java may be much lower or even non-existent, as all string
concatenations in Java use StringBuffer anyway.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This was the same thing I had heard, and it was the basis for my statement
that I thought I was a perfect candidate for using StringBuilder in my code
in place of statements such as:
public static string GetID(...)
{
return contextZero.ID + ciDelimiter + dvZero.ID + ciDelimiter +
contextOne.ID + ciDelimiter + dvOne.ID + ciDelimiter +
contextTwo.ID + ciDelimiter + dvTwo.ID + ciDelimiter +
chDtls.ID + chDtls.IDExtension;
}
Each item in this statement is a string. It's returned in repsonse to a
request for an ID. There are literally hundreds, if not thousands of
statements like this in our code. And they are called LOTS of times --
anytime the ID of an object is required. They should be a critical
performance bottleneck because of this. We considered going with numeric IDs
and several other things, but strings have advantages for us. So I switch to
using StringBuilder.
To my amazement, I found that replacing these string concats with
StringBuilder equivalents actually reduced the measured performance of our
app. Anyone see a flaw or a reason that StringBuilder would falter in a
situation like this?
Dave
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jerry III <je******@hotmail.com> wrote: I think the issue here is doing a lot of concatenations as opposed to
doing a lot of concatenations into one resulting string. Replacing a single
string add with a string builder will definitely make your app slower, no
matter how many times you actually add strings in your app, the advantage of
StringBuilder shows up when you're adding a lot of strings into one
result you use at the end.
Yup, that's absolutely right. Note that I think the threshold for doing
this in Java may be much lower or even non-existent, as all string
concatenations in Java use StringBuffer anyway.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
According to the article in CodeProject, there is a perfectly reasonable
explanation why StringBuilder works the way it does. The "buffer" is
contains is actually a mutable string. Yep, strings are not actually
immutable in .NET.
Why does this matter?
Well, you are actually building a string. Not just building a buffer and
then copying to a string. So in the common case:
1) You create the buffer.
2) You append.
3) You append.
4) You append.
....
297345) You append.
297346) You get the string you just created.
For large strings, this is a TREMENDOUS performance win for the common case,
especially if you make the buffer big enough to hold the entire string.
This eliminates not only a mult-megabyte copy operation, but also prevents
you from having two copies of the huge string in memory at the same time.
It also gets you out of some messy GC.
Of course, if you don't use StringBuilder exactly this way, there can be
some performance side effects.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Jerry III <je******@hotmail.com> wrote: I was talking about concatenating, I have yet to come across code that
uses StringBuilder (or StringBuffer in Java) to replace or remove parts of
the string.
Ah - I have, although I agree that the most common case is just
appending.
In those cases using existing code (those two classes) will be
efficient, but if you only do concatenating you are still far better off
making a guess of how long will your string be and preallocating the
memory yourself - i.e. telling StringBuilder how much it should allocate in the
constructor.
Personally I think it might be worth giving up some speed in ToString
and removing/replacing in order to make appending a lot faster. And if
you're going to ask - no, I don't have any code that proves any of this :(
If you're never going to remove/replace/insert, you probably could
indeed improve the performance. Having said that, a quick attempt to do
so in an obvious way failed. One of the advantages of StringBuilder is
that if you don't need to expand the string in the end, the result of
ToString is just *there* with no further effort.
I might investigate this further though - see if I can come up with
something which beats StringBuilder in the simple case.
I suspect that StringBuilder is rarely the bottleneck in apps, however
- whereas simple repeated string concatenation in a loop easily could
be.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Mountain Bikn' Guy <vc@attbi.com> wrote: This was the same thing I had heard, and it was the basis for my statement
that I thought I was a perfect candidate for using StringBuilder in my code
in place of statements such as:
public static string GetID(...)
{
return contextZero.ID + ciDelimiter + dvZero.ID + ciDelimiter +
contextOne.ID + ciDelimiter + dvOne.ID + ciDelimiter +
contextTwo.ID + ciDelimiter + dvTwo.ID + ciDelimiter +
chDtls.ID + chDtls.IDExtension;
}
Ah no - a statement like that will already be concatenated pretty
efficiently.
Each item in this statement is a string. It's returned in repsonse to a
request for an ID. There are literally hundreds, if not thousands of
statements like this in our code. And they are called LOTS of times --
anytime the ID of an object is required. They should be a critical
performance bottleneck because of this. We considered going with numeric IDs
and several other things, but strings have advantages for us. So I switch to
using StringBuilder.
To my amazement, I found that replacing these string concats with
StringBuilder equivalents actually reduced the measured performance of our
app. Anyone see a flaw or a reason that StringBuilder would falter in a
situation like this?
Yes - the above is a single step concatenation; it doesn't produce a
lot of intermediate strings. The thing to avoid would be converting the
above into stuff like:
public static string GetID(...)
{
string ret = contextZero.ID;
ret += ciDelimiter;
ret += dvZero.ID;
// etc
}
or worse still, doing a lot of concatenations in a loop.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
In article <Pdwkb.826596$uu5.145908@sccrnsc04>, vc@attbi.com says... {
return contextZero.ID + ciDelimiter + dvZero.ID + ciDelimiter +
contextOne.ID + ciDelimiter + dvOne.ID + ciDelimiter +
contextTwo.ID + ciDelimiter + dvTwo.ID + ciDelimiter +
chDtls.ID + chDtls.IDExtension;
}
Each item in this statement is a string.
Yeah, but that's not a lot of concatenations. That's one big
concatenation.
This is a lot of concatenations:
StringBuilder sb = contextZero.ID;
sb += ciDelimiter;
sb += dvZero.ID;
sb += ciDelimiter;
sb += contextOne.ID;
sb += ciDelimiter;
sb += dvOne.ID;
sb += ciDelimiter;
sb += contextTwo.ID;
sb += ciDelimiter;
sb += dvTwo.ID;
sb += ciDelimiter;
sb += chDtls.ID;
sb += chDtls.IDExtension;
-- Rick
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Mountain Bikn' Guy <vc@attbi.com> wrote: This was the same thing I had heard, and it was the basis for my
statement that I thought I was a perfect candidate for using StringBuilder in my
code in place of statements such as:
public static string GetID(...)
{
return contextZero.ID + ciDelimiter + dvZero.ID + ciDelimiter +
contextOne.ID + ciDelimiter + dvOne.ID + ciDelimiter +
contextTwo.ID + ciDelimiter + dvTwo.ID + ciDelimiter +
chDtls.ID + chDtls.IDExtension;
}
Ah no - a statement like that will already be concatenated pretty
efficiently.
Just to add my $.02: the above gets translated to a single
String.Concat(string[]) as oposed to a lot of String.Concat(string) calls.
That's why replacing it with StringBuilder wil actually make the code
slower.
Jerry
public static string GetID(...)
{
string ret = contextZero.ID;
ret += ciDelimiter;
ret += dvZero.ID;
// etc
}
or worse still, doing a lot of concatenations in a loop.
Loop is the key word here :) Especially one that runs couple hundred
times...
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jerry
There's been a lot of fruitful discussions on this subject, I'm not sure
anyone really hit the original question squarely and it deserves an answer.
This is actually a great thread because it shows why even the best minds (no
sarcasm implied here at all) are often fooled when it comes to perf.
Assumptions can easily be wrong, so it's vitally important to measure. I'm
rarely bold enough to predict even the most basic perf results because I
remember how many times I was burned. Certainly I would never make a
statement so bold as "Use Stringbuilders to concatenate" without having a
deeper understanding of the concatenation pattern. I tend to give advice
like "Many users find Stringbuilders useful for their concatenation pattens,
consider using them and measure to see if they help you". Wussy but safe :)
OK, now for some actual, no-kidding-around useful advice (I hope).
When stringbuilders are faster than regular strings it is because of string
allocations and copies that didn't have to happen. Imagine a string builder
that had a buffer that was always the perfect size for the string it held...
it'd be useless right because for sure the next string you appended wouldn't
fit and you'd have to make a new buffer (the new exact size). In fact,
such a stringbuilder wouldn't be very much different than just a string. So
having some slop on the end is important, it's because there's a little room
at the end that we can add things without having to copy.
Well, ok so how much slop? Suppose there was some slop but that the slop
wasn't usually enough to accomodate the appends that happen. Again we'd be
worse off than just strings (strings at least have no slop). There has to
be enough slop that its likely that many appends will fit within the slop,
otherwise there isn't much savings.
Let me break it into 4 cases:
Big string and small appends
=>It's substantially likely that appends will fit in the slop and so they're
fast, this is the best case(buffer size becomes double the string when it no
longer fits so on average the slop is half the current string length) (if
there are lots of small appends to a big string you win the most using
stringbuilder)
Big string and big appends:
=>While the string is comparable in size (or smaller) to the appends
stringbuilder won't save you much, if this continues to the point where the
appends are small compared to the accumlated string you're in the good case
Small string big appends:
=> bad case, string builder will just slow you down until enough slop has
built up to hold those appends, you move to "big string big appends" as you
append and finally to "big string small appends" if/when the buffer becomes
collossal
Small string, small appends:
=> could be ok if you had a good idea how big your string was going to get
and preallocated enough so that you have sufficient slop for the appends.
You might be able to do better if you just concated all the small appends
together in one operation.
One last tip: Sometimes you can get substantial savings by changing
currency in the right places in your algorithm
Pattern A:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
sb += GetMyObjectID(foo,bar); // GetMyObjectID makes a string
Pattern B:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
AppendMyObjectID(sb, foo,bar); // function puts the ID directly into
the buffer
PatternB has no temporary string for the return value, this *might* be
better depending on the nature of the ObjectID composition/calculation.
Something you'd want to measure.
Remember it's all about reducing memory traffic so the competitors are
-the memory in the stringbuilder, including the slop
-the temporary strings (if any) in your algorithm with and without
stringbuilders
-the final output string (note that getting the string out of a
stringbuilder doesn't cause a new alloc, the existing buffer is converted
into a string and then the stringbuilder is logically empty so you don't pay
this cost twice if you use stringbuilder. You do pay for the final output if
you don't use stringbuilder but then you didn't have to pay for the builder
up front)
It's very hard to say which is faster/smaller in general... it's all about
the usage pattern.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Rico Mariani
CLR Performance Architect
"Kevin C" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
Rico,
Thanks for your informative post.
Dave
"Rico Mariani [MSFT]" <ri***@online.microsoft.com> wrote in message
news:u1****************@TK2MSFTNGP12.phx.gbl... There's been a lot of fruitful discussions on this subject, I'm not sure
anyone really hit the original question squarely and it deserves an
answer.
This is actually a great thread because it shows why even the best minds
(no sarcasm implied here at all) are often fooled when it comes to perf.
Assumptions can easily be wrong, so it's vitally important to measure.
I'm rarely bold enough to predict even the most basic perf results because I
remember how many times I was burned. Certainly I would never make a
statement so bold as "Use Stringbuilders to concatenate" without having a
deeper understanding of the concatenation pattern. I tend to give advice
like "Many users find Stringbuilders useful for their concatenation
pattens, consider using them and measure to see if they help you". Wussy but safe
:)
OK, now for some actual, no-kidding-around useful advice (I hope).
When stringbuilders are faster than regular strings it is because of
string allocations and copies that didn't have to happen. Imagine a string
builder that had a buffer that was always the perfect size for the string it
held... it'd be useless right because for sure the next string you appended
wouldn't fit and you'd have to make a new buffer (the new exact size). In fact,
such a stringbuilder wouldn't be very much different than just a string.
So having some slop on the end is important, it's because there's a little
room at the end that we can add things without having to copy.
Well, ok so how much slop? Suppose there was some slop but that the slop
wasn't usually enough to accomodate the appends that happen. Again we'd
be worse off than just strings (strings at least have no slop). There has to
be enough slop that its likely that many appends will fit within the slop,
otherwise there isn't much savings.
Let me break it into 4 cases:
Big string and small appends
=>It's substantially likely that appends will fit in the slop and so
they're fast, this is the best case(buffer size becomes double the string when it
no longer fits so on average the slop is half the current string length) (if
there are lots of small appends to a big string you win the most using
stringbuilder)
Big string and big appends:
=>While the string is comparable in size (or smaller) to the appends
stringbuilder won't save you much, if this continues to the point where
the appends are small compared to the accumlated string you're in the good
case
Small string big appends:
=> bad case, string builder will just slow you down until enough slop has
built up to hold those appends, you move to "big string big appends" as
you append and finally to "big string small appends" if/when the buffer
becomes collossal
Small string, small appends:
=> could be ok if you had a good idea how big your string was going to get
and preallocated enough so that you have sufficient slop for the appends.
You might be able to do better if you just concated all the small appends
together in one operation.
One last tip: Sometimes you can get substantial savings by changing
currency in the right places in your algorithm
Pattern A:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
sb += GetMyObjectID(foo,bar); // GetMyObjectID makes a string
Pattern B:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
AppendMyObjectID(sb, foo,bar); // function puts the ID directly into
the buffer
PatternB has no temporary string for the return value, this *might* be
better depending on the nature of the ObjectID composition/calculation.
Something you'd want to measure.
Remember it's all about reducing memory traffic so the competitors are
-the memory in the stringbuilder, including the slop
-the temporary strings (if any) in your algorithm with and without
stringbuilders
-the final output string (note that getting the string out of a
stringbuilder doesn't cause a new alloc, the existing buffer is converted
into a string and then the stringbuilder is logically empty so you don't
pay this cost twice if you use stringbuilder. You do pay for the final output
if you don't use stringbuilder but then you didn't have to pay for the
builder up front)
It's very hard to say which is faster/smaller in general... it's all about
the usage pattern.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Rico Mariani
CLR Performance Architect
"Kevin C" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
In several of these cases (big loops, lots of concatinations), another
possible methodology would be to store the strings to concantinated in an
array (string array if count of elements known, arraylist if not) then use
string.join to perform the final concatination. This avoids a large
majority of the interim memory allocations, and you just store the
references until the final string data is needed.
Ray Beckett
"Rico Mariani [MSFT]" <ri***@online.microsoft.com> wrote in message
news:u1****************@TK2MSFTNGP12.phx.gbl... There's been a lot of fruitful discussions on this subject, I'm not sure
anyone really hit the original question squarely and it deserves an
answer.
This is actually a great thread because it shows why even the best minds
(no sarcasm implied here at all) are often fooled when it comes to perf.
Assumptions can easily be wrong, so it's vitally important to measure.
I'm rarely bold enough to predict even the most basic perf results because I
remember how many times I was burned. Certainly I would never make a
statement so bold as "Use Stringbuilders to concatenate" without having a
deeper understanding of the concatenation pattern. I tend to give advice
like "Many users find Stringbuilders useful for their concatenation
pattens, consider using them and measure to see if they help you". Wussy but safe
:)
OK, now for some actual, no-kidding-around useful advice (I hope).
When stringbuilders are faster than regular strings it is because of
string allocations and copies that didn't have to happen. Imagine a string
builder that had a buffer that was always the perfect size for the string it
held... it'd be useless right because for sure the next string you appended
wouldn't fit and you'd have to make a new buffer (the new exact size). In fact,
such a stringbuilder wouldn't be very much different than just a string.
So having some slop on the end is important, it's because there's a little
room at the end that we can add things without having to copy.
Well, ok so how much slop? Suppose there was some slop but that the slop
wasn't usually enough to accomodate the appends that happen. Again we'd
be worse off than just strings (strings at least have no slop). There has to
be enough slop that its likely that many appends will fit within the slop,
otherwise there isn't much savings.
Let me break it into 4 cases:
Big string and small appends
=>It's substantially likely that appends will fit in the slop and so
they're fast, this is the best case(buffer size becomes double the string when it
no longer fits so on average the slop is half the current string length) (if
there are lots of small appends to a big string you win the most using
stringbuilder)
Big string and big appends:
=>While the string is comparable in size (or smaller) to the appends
stringbuilder won't save you much, if this continues to the point where
the appends are small compared to the accumlated string you're in the good
case
Small string big appends:
=> bad case, string builder will just slow you down until enough slop has
built up to hold those appends, you move to "big string big appends" as
you append and finally to "big string small appends" if/when the buffer
becomes collossal
Small string, small appends:
=> could be ok if you had a good idea how big your string was going to get
and preallocated enough so that you have sufficient slop for the appends.
You might be able to do better if you just concated all the small appends
together in one operation.
One last tip: Sometimes you can get substantial savings by changing
currency in the right places in your algorithm
Pattern A:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
sb += GetMyObjectID(foo,bar); // GetMyObjectID makes a string
Pattern B:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
AppendMyObjectID(sb, foo,bar); // function puts the ID directly into
the buffer
PatternB has no temporary string for the return value, this *might* be
better depending on the nature of the ObjectID composition/calculation.
Something you'd want to measure.
Remember it's all about reducing memory traffic so the competitors are
-the memory in the stringbuilder, including the slop
-the temporary strings (if any) in your algorithm with and without
stringbuilders
-the final output string (note that getting the string out of a
stringbuilder doesn't cause a new alloc, the existing buffer is converted
into a string and then the stringbuilder is logically empty so you don't
pay this cost twice if you use stringbuilder. You do pay for the final output
if you don't use stringbuilder but then you didn't have to pay for the
builder up front)
It's very hard to say which is faster/smaller in general... it's all about
the usage pattern.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Rico Mariani
CLR Performance Architect
"Kevin C" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
Very nice suggestion!
"Ray Beckett" <ra********@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl... In several of these cases (big loops, lots of concatinations), another
possible methodology would be to store the strings to concantinated in an
array (string array if count of elements known, arraylist if not) then use
string.join to perform the final concatination. This avoids a large
majority of the interim memory allocations, and you just store the
references until the final string data is needed.
Ray Beckett
"Rico Mariani [MSFT]" <ri***@online.microsoft.com> wrote in message
news:u1****************@TK2MSFTNGP12.phx.gbl... There's been a lot of fruitful discussions on this subject, I'm not sure
anyone really hit the original question squarely and it deserves an answer.
This is actually a great thread because it shows why even the best minds
(no sarcasm implied here at all) are often fooled when it comes to perf.
Assumptions can easily be wrong, so it's vitally important to measure.
I'm rarely bold enough to predict even the most basic perf results because I
remember how many times I was burned. Certainly I would never make a
statement so bold as "Use Stringbuilders to concatenate" without having
a deeper understanding of the concatenation pattern. I tend to give
advice like "Many users find Stringbuilders useful for their concatenation
pattens, consider using them and measure to see if they help you". Wussy but
safe :)
OK, now for some actual, no-kidding-around useful advice (I hope).
When stringbuilders are faster than regular strings it is because of string allocations and copies that didn't have to happen. Imagine a string
builder that had a buffer that was always the perfect size for the string it
held... it'd be useless right because for sure the next string you appended
wouldn't fit and you'd have to make a new buffer (the new exact size). In fact,
such a stringbuilder wouldn't be very much different than just a string.
So having some slop on the end is important, it's because there's a little
room at the end that we can add things without having to copy.
Well, ok so how much slop? Suppose there was some slop but that the
slop wasn't usually enough to accomodate the appends that happen. Again we'd
be worse off than just strings (strings at least have no slop). There has
to be enough slop that its likely that many appends will fit within the
slop, otherwise there isn't much savings.
Let me break it into 4 cases:
Big string and small appends
=>It's substantially likely that appends will fit in the slop and so
they're fast, this is the best case(buffer size becomes double the string when
it no longer fits so on average the slop is half the current string length)
(if there are lots of small appends to a big string you win the most using
stringbuilder)
Big string and big appends:
=>While the string is comparable in size (or smaller) to the appends
stringbuilder won't save you much, if this continues to the point where
the appends are small compared to the accumlated string you're in the good
case
Small string big appends:
=> bad case, string builder will just slow you down until enough slop
has built up to hold those appends, you move to "big string big appends" as
you append and finally to "big string small appends" if/when the buffer
becomes collossal
Small string, small appends:
=> could be ok if you had a good idea how big your string was going to
get and preallocated enough so that you have sufficient slop for the
appends. You might be able to do better if you just concated all the small
appends together in one operation.
One last tip: Sometimes you can get substantial savings by changing
currency in the right places in your algorithm
Pattern A:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
sb += GetMyObjectID(foo,bar); // GetMyObjectID makes a string
Pattern B:
StringBuilder sb = new StringBuilder(SuitableSize);
// sb gets a bunch of stuff
AppendMyObjectID(sb, foo,bar); // function puts the ID directly
into the buffer
PatternB has no temporary string for the return value, this *might* be
better depending on the nature of the ObjectID composition/calculation.
Something you'd want to measure.
Remember it's all about reducing memory traffic so the competitors are
-the memory in the stringbuilder, including the slop
-the temporary strings (if any) in your algorithm with and without
stringbuilders
-the final output string (note that getting the string out of a
stringbuilder doesn't cause a new alloc, the existing buffer is
converted into a string and then the stringbuilder is logically empty so you don't
pay this cost twice if you use stringbuilder. You do pay for the final
output if you don't use stringbuilder but then you didn't have to pay for the
builder up front)
It's very hard to say which is faster/smaller in general... it's all
about the usage pattern.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Rico Mariani
CLR Performance Architect
"Kevin C" <ke************@sbcglobal.net> wrote in message
news:E0****************@newssvr27.news.prodigy.com ... Quick Question:
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 '+='?
Cheers,
-k
Does anyone know what the default allocation size is for StringBuilder if you do
not explicitly initialize the instance?
This doesn't actually compile does it? I tried += with the a StringBuilder
object and the compiler gave an error such as:
Cannot convert type 'string' to 'System.Text.StringBuilder'
On Mon, 20 Oct 2003 10:52:17 -0700, Guinness Mann <GM***@dublin.com> wrote: This is a lot of concatenations:
StringBuilder sb = contextZero.ID;
sb += ciDelimiter;
sb += dvZero.ID;
sb += ciDelimiter;
sb += contextOne.ID;
sb += ciDelimiter;
sb += dvOne.ID;
sb += ciDelimiter;
sb += contextTwo.ID;
sb += ciDelimiter;
sb += dvTwo.ID;
sb += ciDelimiter;
sb += chDtls.ID;
sb += chDtls.IDExtension;
Hi Kerry,
Paste this into a VB Form and put a breakpoint on the Append.
Add sb to a Watch window and see what happens to Capacity and
Length as you do each Append. Most illuminating.
Dim sb as New StringBuilder
Dim I As Integer
For I = 1 To 20
sb.Append ("123456789012345")
Next
And that's why, when you have a large StringBuilder, you should set
the capacity to, or just above, the most that you'll want.
Regards,
Fergus
Kerry Sanders <di****@NOSPAMyahoo.com> wrote: Does anyone know what the default allocation size is for StringBuilder if you do
not explicitly initialize the instance?
Well, just a very simple test (creating a new StringBuilder and showing
its Capacity) shows it as 16 if you don't specify any string, or the
lowest power of 2 which is greater than the length of the initial
string if you *do* specify a string.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Hi Kerry,
Using Reflector (look on Google for Lutz Reflector) to decompile the source
is a good way to get the answer to questions like this. An alternative is
to look at the Rotor source code.
There's a definite performance benefit in getting the size of the buffer
right before you start using it. StringBuilder, like most of things in .NET
that allocate dynamically, allocate by *2 each time. So, StringBuilder goes
16 bytes, 32 bytes, 64 bytes, and so on. This gets a bit scary when you
have 1MB, because as soon as you add that next byte it goes direct to 2MB.
In most cases, the allocation approach isn't a problem, but it's worth
remembering that it has this behaviour in case you start using it in
situations where optimization by guestimating the size of the buffer by the
time you're finished may help you. (Think about generating large strings,
such as XML documents.)
--
Cheers,
Matthew http://www.dotnet247.com/ http://weblogs.asp.net/mreynolds/
"Kerry Sanders" <di****@NOSPAMyahoo.com> wrote in message
news:20********************************@4ax.com... Does anyone know what the default allocation size is for StringBuilder if
you do not explicitly initialize the instance?
>Using Reflector (look on Google for Lutz Reflector) to decompile the source is a good way to get the answer to questions like this. An alternative is
to look at the Rotor source code.
I actually found, downloaded, and looked at Reflector last night after posting
that message. For some reason, a method in one of my classes is causing
Reflector to fail to open my assembly. I do not know why, however. The error I
received is as follows
Method GetColumns in type InventoryList from assembly Inventory,
Version=2.2.0.0, Culture=neutral, PublicKeyToken=null does not have an
implementation
Any thoughts on this? The assembly compiles with no problems. I do not
understand the meaning behind this particular error.
Kerry Sanders <di****@NOSPAMyahoo.com> wrote: Using Reflector (look on Google for Lutz Reflector) to decompile the source
is a good way to get the answer to questions like this. An alternative is
to look at the Rotor source code.
I actually found, downloaded, and looked at Reflector last night after posting
that message. For some reason, a method in one of my classes is causing
Reflector to fail to open my assembly. I do not know why, however. The error I
received is as follows
Method GetColumns in type InventoryList from assembly Inventory,
Version=2.2.0.0, Culture=neutral, PublicKeyToken=null does not have an
implementation
Any thoughts on this? The assembly compiles with no problems. I do not
understand the meaning behind this particular error.
I think it's almost certainly a bug in Reflector - if you can, I think
it would be worth mailing the author, including your assembly and a
description of the problem.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
>I think it's almost certainly a bug in Reflector - if you can, I think it would be worth mailing the author, including your assembly and a
description of the problem.
Thanks Jon. I will do that.
In article <o7********************************@4ax.com>, di****@NOSPAMyahoo.com says...
This doesn't actually compile does it? I tried += with the a StringBuilder
object and the compiler gave an error such as:StringBuilder sb = contextZero.ID;
sb += ciDelimiter;
sb += dvZero.ID;
....
Sorry, got carried away. S/B sb.Append(ciDelimiter), etc.
-- Rick This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Bob |
last post by:
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...
|
by: Kevin C |
last post by:
Quick Question:
StringBuilder is obviously more efficient dealing with string concatenations
than the old '+=' method... however, in dealing with relatively large string
concatenations (ie,...
|
by: genc_ymeri |
last post by:
Hi over there,
Propably this subject is discussed over and over several times. I did google
it too but I was a little bit surprised what I read on internet when it
comes 'when to use what'.
Most...
|
by: Richard Lewis Haggard |
last post by:
I thought that the whole point of StringBuilder was that it was supposed to
be a faster way of building strings than string. However, I just put
together a simple little application to do a...
|
by: bharathreddy |
last post by:
Everyone use the type String in their daily programming more often. In addition, most of people do a common mistake to choose between String and StringBuilder.
In concatenation of Strings,...
|
by: pantagruel |
last post by:
Hi,
It is generally stated that stringbuilder should be used instead of
just concatenating strings with the plus operator.
That's fine enough what I'm wondering in cases I have:
String S =...
|
by: raylopez99 |
last post by:
StringBuilder better and faster than string for adding many strings.
Look at the below. It's amazing how much faster StringBuilder is than
string.
The last loop below is telling: for adding...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
