String and StringBuilder

[Harvey Triana]

Thanks to all.

<HT>

Oh thanks, this is a good discussion. Suggest another question:

When i write:
return IntegerPart + " " + MoneyName + " " & RealPart;

- how may strings are create before Return is a single string?

Should be use ScringBuilder in this case?

<HT />

 

[Jon Skeet [C# MVP]]

Just to be formal ...

There may be more objects created than with the stringbuilder it really
depends on what the variables come out as and the initial size of the
stringbuilder object (although I agree with you that the stringbuilder in
bad code here).

Well, String.Concat (which is used internally) would deal with the 5
input strings, and then come out with one output string.

Is your point that StringBuilder might not need to convert IntegerPart,
MoneyPart and RealPart into strings first? I hadn't thought of that...

 

[Jon Skeet [C# MVP]]

the answer here is (n -1) ... 4 ... since these strings are all short its
not too big of a deal (the copies are of say 8 bytes as opposed to 800 or
8000)

No extra strings are created for the concatenation. IntegerPart,
MoneyName and RealPart are converted into strings, but it *doesn't*
calculate (IntegerPart + " "), then add MoneyName to that, then add
" " to that, then RealPart.

Instead, it calls String.Concat. Unfortunately in this case it needs to
use String.Concat(String[]) as there are only overloads for
String.Concat as far as four strings. It doesn't build up any temporary
strings though, beyond the strings to concatenate in the first place.

 

[Greg Young]

Yes Jon although in the current implementation does create those strings ...

public StringBuilder Append(int value)
{
return this.Append(value.ToString(CultureInfo.CurrentCulture));
}

Theoretically the implementation could create the string versions directly
in its buffer.

Cheers,

Greg

 

[Guest]

I guess you don't find it important until it takes a full second as opposed

to < 100 ms?

and until the response time is important (performance).
I see no reason to stick SB wherever it possible. On the back-end - indeed,
but on client - arguably, till we have no the reason for this(like number of
string in cycle)

This is already atleast 10 times faster and can make a HUGE
difference in the running time of your app as this is a CPU bound task (it
uses 100% CPU on a CPU while doing this which means if you do this alot your
CPU usage will needlessly go up).

Sure, but it depends on type of app, whether it concerns us or not

Your code also only runs it once which completely ignores the GC penalty
incurred by the string methodology. Which my guess would make it closer to
15-20 times slower.

yes, but we haven't discuss how much it should be run we just concatenate
strings
If we need to run in several times Strings are not appropriate

The penalty for using a SB is NEVER severe if used properly (unless you are
concating say 2 strings) .. the penalty is only severe for using strings ...
that is why it is best to error on the side of caution and use a
stringbuilder.

There I was talking about strings mistyped.

I'm not arguing that Strings are good and "use String wherever it possible"
I want to say that the String isn't the evil as we discuss there , but it
could be the evil if we dont understand how and where to use Strings or SB.
We need to see the app where OP use it, how and when.
What to say if we are struggling to save 1-2 seconds and then below in code
we could see the huge XSLT transformation that isn't optimized and takes 30
secs. Those saved 1-2 sec doesn't make any sense in this context

I've been reviewing code periodically, and have seen a lot of times that
people sticks SB even to concanting 2-3 strings, where you can use strings.
And this hasty using SB (because smbd have read somewhere that is very quick)
really influence on code readability. We are most read code rather then write
it.

Optimizing is for that have to be optimizing

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Jon Skeet [C# MVP]]

and until the response time is important (performance).
I see no reason to stick SB wherever it possible. On the back-end - indeed,
but on client - arguably, till we have no the reason for this(like number of
string in cycle)

That's very different from claiming there's no visible difference until
you concatenate about 25,000 strings though. Having a known but
acceptable performance hit is one thing - claiming the hit isn't there
is another.

Yes, the times taken are both small - in the same way that both an atom
and a speck of dust are small. There's still a vast difference between
them in size though - and it's misleading to imply that there isn't, as
your post did IMO.

Jon

 

[Michael Nemtsev]

Hello Jon Skeet [C# MVP],

J> Michael Nemtsev wrote:
J>J> That's very different from claiming there's no visible difference
J> until you concatenate about 25,000 strings though. Having a known but
J> acceptable performance hit is one thing - claiming the hit isn't
J> there is another.

Jon I didn't claim that hit absolutely isn't here. I pointed that "it depends
on your environment", and in the last post I've expained what I meant.

J> Yes, the times taken are both small - in the same way that both an
J> atom and a speck of dust are small. There's still a vast difference
J> between them in size though - and it's misleading to imply that there
J> isn't, as your post did IMO.

Probably, I wasn't clear to point my idea

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch