StringBuilder much much faster and better than String forconcatenation !!!

[Bill Butler]

I'm curious how you did such a quick test, especially since the
DateTime structure is only accurate to at best 10 ms or greater.

You simply repeat each test about 100,000 times in a loop.
Viola!

 

[raylopez99]

You simply repeat each test about 100,000 times in a loop.
Viola!

But Peter said: > For what it's worth, curious I did a quick test. I
found that the two

techniques reach near-parity at just 5 concatenations, and StringBuilder
is definitively faster at 10 concatenations. At 20, there's no contest.

Which implies he only tested five concatenations, and up to 20, no
more.

RL

 

[Jon Skeet [C# MVP]]

But Peter said:

Which implies he only tested five concatenations, and up to 20, no
more.

You can repeatedly do 20 concatenations though. Doing 20
concatenations 100,000 times is not the same thing as doing 20 *
100,000 concatenations.

Jon

 

[raylopez99]

You can repeatedly do 20 concatenations though. Doing 20
concatenations 100,000 times is not the same thing as doing 20 *
100,000 concatenations.

OK, I see. Do 20 loops, store the time difference, and repeat 100k
times. Makes sense.

RL

 

[Jon Skeet [C# MVP]]

OK, I see.  Do 20 loops, store the time difference, and repeat 100k
times.  Makes sense.

Not quite. The point is to only compare the times at the very start
and end:

1) Start Stopwatch (System.Diagnostics.Stopwatch)
2) Concatenate string 20 times
3) Repeat step 2 100,000 times
4) Stop Stopwatch
5) Report results

Jon

 

[not_a_commie]

I'm curious how you did such a quick test, especially since the

DateTime structure is only accurate to at best 10 ms or greater.

Yeah, DateTime subtraction is a terrible way to time stuff. Use the
Stopwatch.Elapsed.TotalSeconds instead. (And be warned that if you are
running on a motherboard with multiple sockets Stopwatch won't work
right without Vista or manually setting the CPU affinity on your
thread.)

 

[raylopez99]

I've been looking for a decent stopwatch, and have checked out various
MSDN articles that say it really can't be done (the one that says "if
you're looking for a metronome, you've come to the wrong place").

If you have code or pseudo code on this "Stopwatch" method, please
post here so I can add it to my bag of tricks aka library.

Thank you,

RL

 

[Jon Skeet [C# MVP]]

I've been looking for a decent stopwatch, and have checked out various
MSDN articles that say it really can't be done (the one that says "if
you're looking for a metronome, you've come to the wrong place").

If you have code or pseudo code on this "Stopwatch" method, please
post here so I can add it to my bag of tricks aka library.

As I said before, see System.Diagnostics.Stopwatch. (It's not a method,
it's a type.)

Simple example:

using System;
using System.Diagnostics;

class Test
{
static void Main()
{
Stopwatch sw = Stopwatch.StartNew();
// Do something expensive
string x = "";
for (int i=0; i < 100000; i++)
{
x += " "; // Eek!
}

sw.Stop();
Console.WriteLine("Elapsed time: {0}ms",
sw.ElapsedMilliseconds);
}
}

 

[not_a_commie]

sw.ElapsedMilliseconds

On a decent motherboard you should be able to get near microsecond
accuracy with that, which means you probably want to use
sw.Elapsed.TotalMilliseconds instead of sw.Milliseconds. I've also
seen a few weird glitches with the latter where occasionally the
machine will hiccup and you'll be off by six orders of magnitude.

 

[Jon Skeet [C# MVP]]

On a decent motherboard you should be able to get near microsecond
accuracy with that, which means you probably want to use
sw.Elapsed.TotalMilliseconds instead of sw.Milliseconds.

I disagree. If your test is so sensitive that +/- 1ms makes any
difference, it's running for way too short a time to be meaningful,
IMO. I'd be very suspicious of any test running in less than a second
- and moderately suspicious of a test running in less than 10 seconds,
unless it's to show that (say) an algorithm taking 5 seconds is much
slower than one taking half a second. The variation between runs is
very, very rarely going to be less than a millisecond, so where's the
benefit in giving more precision? The benefit of giving *less*
precision is that Integers are, IMO, easier to immediately recognise
in terms of magnitude than reals. It's easier to compare at a glance,
say, 12532 and 3250 than 12532.23401 and 3250.195323.

I've also
seen a few weird glitches with the latter where occasionally the
machine will hiccup and you'll be off by six orders of magnitude.

That's very odd - never seen anything like that.

Jon

 

[raylopez99]

On a decent motherboard you should be able to get near microsecond
accuracy with that, which means you probably want to use
sw.Elapsed.TotalMilliseconds instead of sw.Milliseconds. I've also
seen a few weird glitches with the latter where occasionally the
machine will hiccup and you'll be off by six orders of magnitude.

Thanks !commie. On a related note, I've seen strange stuff with
garbage collected timers, they tend to "bunch up" and/or 'hiccup'
where they don't fire on time. The DateTime structure also has
a .Ticks "total milliseconds" (actually I think it's close to
nanoseconds, or some multiple of ns) from the year 0 AD that's also
good but the granularity of DateTime is >= 10ms, so that defeats the
purpose.

Thanks to you and Jon for the hint--I've but this into my bag of
tricks.

RL

 

[Jon Skeet [C# MVP]]

Thanks !commie.  On a related note, I've seen strange stuff with
garbage collected timers, they tend to "bunch up" and/or 'hiccup'
where they don't fire on time.  The DateTime structure also has
a .Ticks "total milliseconds" (actually I think it's close to
nanoseconds, or some multiple of ns) from the year 0 AD that's also
good but the granularity of DateTime is >= 10ms, so that defeats the
purpose.

The granularity of DateTime itself is fine - it's the granularity of
the timer that DateTime.Now uses that makes it less suitable than
Stopwatch for performance timing.

Jon

 

[Jon Skeet [C# MVP]]

Thanks !commie.  On a related note, I've seen strange stuff with
garbage collected timers, they tend to "bunch up" and/or 'hiccup'
where they don't fire on time.  The DateTime structure also has
a .Ticks "total milliseconds" (actually I think it's close to
nanoseconds, or some multiple of ns) from the year 0 AD that's also
good but the granularity of DateTime is >= 10ms, so that defeats the
purpose.

The granularity of DateTime itself is fine - it's the granularity of
the timer that DateTime.Now uses that makes it less suitable than
Stopwatch for performance timing.

Jon