Question about performance (very simple example given).

[-Lost]

Question about performance (very simple example given).

I read in the MSDN Express documentation that when concatenating
large strings that it is actually more efficient to build them with
StringBuilder.

My professor however told me this is wrong, and specifically that I
was wrong for using StringBuilder in this case:

"Build a string that consists of the numbers 1 through 100, no
spaces, no newlines."

So I did this:

StringBuilder strOneToOneHundred = new StringBuilder();
for (int i = 1; i <= 100; i++)
{
strOneToOneHundred.Append(i);
}
Console.Write(strOneToOneHundred);

He told me that in this case it was overkill and then suggested I
"stick to writing to the console." I asked what that meant and he
replied, "just use console write to output it to the console."

Surely he didn't mean:

Console.Write("1");
// 98 more Console.Writes
Console.Write("100");

So, is StringBuilder overkill in this case? Are numerous (as in tens
and tens of them) Console.Write's smarter? More efficient?

And before anyone asks... I was told not to use Arrays.

 

[Jon Skeet [C# MVP]]

Question about performance (very simple example given).

I read in the MSDN Express documentation that when concatenating
large strings that it is actually more efficient to build them with
StringBuilder.

My professor however told me this is wrong, and specifically that I
was wrong for using StringBuilder in this case:

"Build a string that consists of the numbers 1 through 100, no
spaces, no newlines."

So I did this:

StringBuilder strOneToOneHundred = new StringBuilder();
for (int i = 1; i <= 100; i++)
{
strOneToOneHundred.Append(i);}

Console.Write(strOneToOneHundred);

He told me that in this case it was overkill and then suggested I
"stick to writing to the console." I asked what that meant and he
replied, "just use console write to output it to the console."

Well, that doesn't solve the original problem. You were asked to
*build a string*, not *write the numbers to the console*.

Just calling Console.Write *may* be faster (I doubt it, but you could
measure) but the point is that it doesn't build up a string object
with the same data.

If he wants to change the problem, that's fine - but that should be
done explicitly, rather than just by giving an answer to a different
problem.

Jon

 

[Mythran]

Question about performance (very simple example given).

I read in the MSDN Express documentation that when concatenating
large strings that it is actually more efficient to build them with
StringBuilder.

My professor however told me this is wrong, and specifically that I
was wrong for using StringBuilder in this case:

"Build a string that consists of the numbers 1 through 100, no
spaces, no newlines."

So I did this:

StringBuilder strOneToOneHundred = new StringBuilder();
for (int i = 1; i <= 100; i++)
{
strOneToOneHundred.Append(i);
}
Console.Write(strOneToOneHundred);

He told me that in this case it was overkill and then suggested I
"stick to writing to the console." I asked what that meant and he
replied, "just use console write to output it to the console."

Well, after performing 4 loops (1 through 100 - 4 times) using concatenation
and then using StringBuilder, there is NO difference in speed on my machine.
All 4 times registered < 1ms for each loop. I don't think, on a reasonably
fast machine, that either case will be noticeably faster or slower. But to
simply say StringBuilder is overkill IMHO is a mistake. StringBuilder is
not overkill when building a string in a loop...that's what it's for!
StringBuilder would be overkill if you are appending small strings together
which, overall, will form a small string. At which point a small string
becomes a string that's not overkill for the StringBuilder? I am not sure,
but if you are using a loop to concatenate strings, StringBuilder is a good
choice. BUT, I would still do as your professor asks, as his way will get
you a better grade than going against the grain in this situation It is
HIS assignment after all.

(in this example, I wouldn't have used a StringBuilder for my own
application, it's not overkill, but it's not building a string big enough to
cause me to lose sleep)

HTH,
Mythran

 

[Scott Roberts]

(in this example, I wouldn't have used a StringBuilder for my own

application, it's not overkill, but it's not building a string big enough
to cause me to lose sleep)

That's the problem with examples - they're not real.

What is the likelihood that the loop will increase from 100 iterations to
1000? To 1,000,000? To some arbitrary number? What is the likelihood that
the text being appended inside each iteration will need to be changed?

IMO, the choice of construct should be weighed against code maintainability.
The example doesn't do anything useful, so it's impossible to answer these
questions.

 

[Brian Gideon]

Well, after performing 4 loops (1 through 100 - 4 times) using concatenation
and then using StringBuilder, there is NO difference in speed on my machine.
All 4 times registered < 1ms for each loop.  I don't think, on a reasonably
fast machine, that either case will be noticeably faster or slower.   But to
simply say StringBuilder is overkill IMHO is a mistake.  StringBuilder is
not overkill when building a string in a loop...that's what it's for!
StringBuilder would be overkill if you are appending small strings together
which, overall, will form a small string.  At which point a small string
becomes a string that's not overkill for the StringBuilder?  I am not sure,
but if you are using a loop to concatenate strings, StringBuilder is a good
choice.  BUT, I would still do as your professor asks, as his way will get
you a better grade than going against the grain in this situation  Itis
HIS assignment after all.

(in this example, I wouldn't have used a StringBuilder for my own
application, it's not overkill, but it's not building a string big enough to
cause me to lose sleep)

HTH,
Mythran

4 loops of 1 to 100 isn't nearly enough to make any conclusions about
the performance differences of StringBuilder versus concatenation even
if you were using the high precision Stopwatch class for timing.

 

[Peter Duniho]

Question about performance (very simple example given).

I read in the MSDN Express documentation that when concatenating
large strings that it is actually more efficient to build them with
StringBuilder.

True. Though, to some extent it's as much about a large number of strings
as it is about strings that are large.

My professor however told me this is wrong, and specifically that I
was wrong for using StringBuilder in this case:

"Build a string that consists of the numbers 1 through 100, no
spaces, no newlines."

Sounds like a fine time to use StringBuilder.

So I did this:

StringBuilder strOneToOneHundred = new StringBuilder();
for (int i = 1; i <= 100; i++)
{
strOneToOneHundred.Append(i);
}
Console.Write(strOneToOneHundred);

Looks great.

He told me that in this case it was overkill and then suggested I
"stick to writing to the console." I asked what that meant and he
replied, "just use console write to output it to the console."

Surely he didn't mean:

Console.Write("1");
// 98 more Console.Writes
Console.Write("100");

Well, he might have meant:

for (int i = 1; i <= 100; i++)
{
Console.Write(i);
}

But like Jon says, that's different from the quote you provided for the
assignment, and so assuming you've quoted your professor exactly, the
above isn't a solution to the problem he assigned.

You should give your professor the benefit of the doubt and offer him the
opportunity to explain himself further. There should be no need to ask
_us_ what he meant or how to go about solving the problem. A good teacher
will be able to make that clear to you.

That said, there are plenty of bad teachers. I have noticed that one way
in which teachers can be bad is that they don't deal well with students
who present them with new knowledge. My own experience has been that one
of the best ways to learn something is to teach it. Between being
required to know something better to teach it, and being exposed to
students who come from different experience levels and abilities and thus
who can present you with more information, teaching is a great way to
learn.

But not all teachers subscribe to this theory and instead view students
varying from their strict idea of how to approach a problem as a threat.
When presented with that threat, they criticize the student and/or their
technique rather than taking advantage of the learning opportunity.

Hopefully that's not what's going on here, but just from what you wrote is
sure seems like it is. Because there's a distinct possibility that we
simply don't have all the facts, I don't want to say that your teacher is
just being a bone-head. You should, as I mentioned, given him the benefit
of the doubt for now and see if you can get him to clarify. But it's
possible he is just being a bone-head. In which case, you pretty much
just need to figure out on your own what exactly he wants, give it to him,
and move on.

And no, using StringBuilder is definitely _not_ overkill. This is a great
example of a situation in which using StringBuilder is useful, even if the
specific input is so small that the immediate application doesn't benefit
much from it. Heck, if you wanted to you could improve the performance a
little more by providing the StringBuilder instance with an initial
capacity, since you know ahead of time how many characters you're going to
store in it.

Pete

 

[Peter]

Heck, if you wanted to you could
improve the performance a little more by providing the StringBuilder
instance with an initial capacity, since you know ahead of time how
many characters you're going to store in it.

Well why can't you just assign the string directly:
string s = "1234567891011121314...


--

 

[Peter Duniho]

Well why can't you just assign the string directly:
string s = "1234567891011121314...

I guess that depends on your definition of "build".

To me, "build" implies multiple steps of construction. I would describe
your code as "assign" rather than "build".

But sure, if the professor considers a single string assignment as a valid
example of "building", your example should be acceptable.

Pete

 

[-Lost]

Response to "Peter Duniho" <[email protected]>:

Sounds like a fine time to use StringBuilder.


Looks great.


Well, he might have meant:

for (int i = 1; i <= 100; i++)
{
Console.Write(i);
}

Or that, sure. Although in no way shape or form is that building a
string object -- which you knew of course. Which brings me to your
comments about the professor...

But like Jon says, that's different from the quote you provided
for the assignment, and so assuming you've quoted your professor
exactly, the above isn't a solution to the problem he assigned.

*Exact* quote.

You should give your professor the benefit of the doubt and offer
him the opportunity to explain himself further. There should be
no need to ask _us_ what he meant or how to go about solving the
problem. A good teacher will be able to make that clear to you.

He replied with, "Well, to be fair to myself, I do not have 100%
complete knowledge of every single problem that is written in this
textbook."

I'm not sure how that answers the question at hand, but it sure makes
me worry a bit more.

That said, there are plenty of bad teachers. I have noticed that
one way in which teachers can be bad is that they don't deal well
with students who present them with new knowledge. My own
experience has been that one of the best ways to learn something
is to teach it. Between being required to know something better
to teach it, and being exposed to students who come from
different experience levels and abilities and thus who can
present you with more information, teaching is a great way to
learn.

But not all teachers subscribe to this theory and instead view
students varying from their strict idea of how to approach a
problem as a threat. When presented with that threat, they
criticize the student and/or their technique rather than taking
advantage of the learning opportunity.

I could be wrong, but I am seriously concerned about this course
because I stated up front that I had knowledge about the different
concepts (but that I was not a great programmer nor was I familiar
with C#), and he has spent the entire time giving me "life lessons"
and these long drawn out stories about how I need to be safe and slow
down. (Whatever the hell that is supposed to mean.)

Hopefully that's not what's going on here, but just from what you
wrote is sure seems like it is. Because there's a distinct
possibility that we simply don't have all the facts, I don't want
to say that your teacher is just being a bone-head. You should,
as I mentioned, given him the benefit of the doubt for now and
see if you can get him to clarify. But it's possible he is just
being a bone-head. In which case, you pretty much just need to
figure out on your own what exactly he wants, give it to him, and
move on.

That has been my general idea from the beginning, but I am wrong far
too often on most things so wasn't quite sure if I was just blowing
it out of proportion.

Done and done.

And no, using StringBuilder is definitely _not_ overkill. This is
a great example of a situation in which using StringBuilder is
useful, even if the specific input is so small that the immediate
application doesn't benefit much from it. Heck, if you wanted to
you could improve the performance a little more by providing the
StringBuilder instance with an initial capacity, since you know
ahead of time how many characters you're going to store in it.

Thanks, Pete. Honestly I did not know that could be done (yet).

I'll continue trying to learn beside what I am being fed, you guys
(and gals?) will surely straighten me out.

Thanks again.

 

[Arne Vajhøj]

That's the problem with examples - they're not real.

What is the likelihood that the loop will increase from 100 iterations
to 1000? To 1,000,000? To some arbitrary number? What is the likelihood
that the text being appended inside each iteration will need to be changed?

It is very unlikely that real requirements increase by a
factor 1000, but it is frequently seen that real data are 1000
times bigger than the test data the developer is using.

Arne

 

[Scott Roberts]

It is very unlikely that real requirements increase by a
factor 1000

On what do you base that statement?

I only said that you need to assess the likelihood. If it's low, then don't
worry about it.

 

[Arne Vajhøj]

On what do you base that statement?

The requirements is somewhat dependent on business.

Even though it is very fortunate of ones business turns
out to be 1000 times bigger than planned, then it is
not likely.

Arne