String foreach problem

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I don't require a concrete guarantee - just some idea of the number of
iterations. If there are a lot of iterations, StringBuilder is the best
choice - agreed. I'm just questioning how many times that happens. My
definition of "a lot" is the same as yours, I suspect - where performance
degradation is noticeable.

It's not only a question of performance, but also about scalability.
Systems tend to grow over time, so many times it's better to choose a
method that scales well rather than a method that performs well when
testing with a certain amount of data.

If you have ten strings, using Concat might be faster than using a
StringBuilder. Even if you have 20 string, perhaps even 30. After that
it starts getting bad, and fast. Every single additional string means
that you use twice as much memory to concatenate them.

As long as you don't have much data, performance isn't really a problem
anyway. It's when the data starts to grow that it shows if you are able
to write scalable code.

 

[Peter Duniho]

[...]
If you have ten strings, using Concat might be faster than using a
StringBuilder. Even if you have 20 string, perhaps even 30. After that
it starts getting bad, and fast. Every single additional string means
that you use twice as much memory to concatenate them.

As long as you don't have much data, performance isn't really a problem
anyway. It's when the data starts to grow that it shows if you are able
to write scalable code.

Exactly. And just in case Göran's point wasn't clear enough:

If you have so few strings to concatenate that concatention is faster than
using StringBuilder, then _neither_ implementation is likely to be of any
significance with respect to performance.

It is only when the number of strings gets large that the performance
matters, and StringBuilder will always be better in those scenarios.

Pete

 

[Mark Wilden]

It is only when the number of strings gets large that the performance
matters, and StringBuilder will always be better in those scenarios.

I agree, but that doesn't have the slightest thing to do with what I've been
saying.

///ark

 

[Peter Duniho]

I agree, but that doesn't have the slightest thing to do with what I've
been
saying.

Not the slightest? Surely it has at least a little to do with what
"you've been saying". In particular, the post to which I replied (and the
only one I've had a comment on) claimed that no one would ever have to
concatenate a string so long that StringBuilder would be better than
concatenation.

That sure seems to be directly relevant to what Göran wrote, as well as my
reply to him to which you replied.

In any case, we might quibble about just _how_ relevant the two are, but
it seems obviously wrong that it "doesn't have the slightest thing" in
relevance.

Pete

 

[mark]

Pete, I completely agree that when the number of strings get large,
StringBuilder is better than +. I've never said otherwise. Telling me
that is preaching to the choir.

My point has been to question the need to concatenate large numbers of
strings. At first, I couldn't imagine a good reason to do so.
Actually, I still can't, since I haven't seen a good example yet. But
I won't deny there are cases where that need exists (even if no one
can think of one easily).

I'll say it just one last time: I think concatenating a large number
of strings represents a "code smell." Nothing to do with
StringBuilder.

///ark

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Pete, I completely agree that when the number of strings get large,
StringBuilder is better than +. I've never said otherwise. Telling me
that is preaching to the choir.

My point has been to question the need to concatenate large numbers of
strings. At first, I couldn't imagine a good reason to do so.
Actually, I still can't, since I haven't seen a good example yet. But
I won't deny there are cases where that need exists (even if no one
can think of one easily).

I'll say it just one last time: I think concatenating a large number
of strings represents a "code smell." Nothing to do with
StringBuilder.

///ark

An example of a very common use, is a web page. When ASP.NET renders a
web page, the html code for each element of the page is put into a
single large string. This is often hundreds of strings, perhaps
thousands, and the resulting string may be several kilobytes.

Of course it's done using a StringBuilder.

 

[Mark Wilden]

An example of a very common use, is a web page. When ASP.NET renders a web
page, the html code for each element of the page is put into a single
large string.

Example accepted.

However, this is not common. Not many of us write our own web framework, so
I still stick to "rare."

///ark

 

[steve.falzon@]

Example accepted.

However, this is not common. Not many of us write our own web framework, so
I still stick to "rare."

///ark

Hi Mark

Another example would be building a data file with, say, daily share
dealing information. Customer details and their share dealings for a
day are processed at close of business and submitted to an external
company for processing on their systems to check whether the deals are
valid and comply with money laundering regulations, for instance.

The data files may contain transactions by thousands of customers and
an unspecified but numerous number of deals. Often the legacy systems
still in use are not setup to process this information real-time and
so the datafile is built and transferred at close of business. Once
processed the results are returned using a similar process.

There are many other instances where business requires bulk processing
of strings.

Steve

 

[Mark Wilden]

Another example would be building a data file with, say, daily share
dealing information.

Why not just write to the file directly?

///ark

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Example accepted.

However, this is not common. Not many of us write our own web framework, so
I still stick to "rare."

What do you accept the example as, if you don't accept it as an example?
Doesn't it count because the guys at microsoft wrote the code?

It's used millions of time every day, I wouldn't call that "rare"...

 

[Mark Wilden]

What do you accept the example as, if you don't accept it as an example?

It's an example of a legitimate (IMO) reason for creating long strings.

It's used millions of time every day, I wouldn't call that "rare"...

This is a programmer's forum. I think it's rare in programming to create
long strings. Only Microsoft creates the long strings in your example.

///ark