On Sat, 24 May 2008 16:37:31 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
Is string.Split() performant to a degree that there's no point in trying
to write code to improve on its performance ?
I would expect so. But if it's important to you, you can always test its
performance yourself to determine for sure.
I certainly wouldn't waste any time writing my own implementation until
I'd proved that my program was spending an inordinate amount of time in
the String.Split() method.
"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.ubonamv 18jd0ej@petes-computer.local. ..
On Sat, 24 May 2008 16:37:31 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
>
>Is string.Split() performant to a degree that there's no point in trying
>to write code to improve on its performance ?
>
I would expect so. But if it's important to you, you can always test its
performance yourself to determine for sure.
>
I certainly wouldn't waste any time writing my own implementation until
I'd proved that my program was spending an inordinate amount of time in
the String.Split() method.
>
Pete
Is string.Split() performant to a degree that there's no point in trying
to write code to improve on its performance ?
In general you should expect that MS has optimized
all the mostly used methods. I am sure that they run
profilers on .NET apps and see where in the library
there are bottlenecks.
A quick look at the source code gives me the impression that
the code is fast but use some memory.
Given that I find it very unlikely that you will be
able to write some split code that will increase
your app code measurable. It is much more likely
that you will be able to increase maintenance cost !
On Sat, 24 May 2008 17:11:32 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
Hi Peter, and thanks for the response.
>
What about string.Replace( ) ... ?
>
Same answer ?
I would reply with basically the same answer for nearly every method in
the .NET Framework. Especially the part about not worrying about it until
you've proved it's a performance bottleneck.
There are certainly dumb, inefficient ways to do things in .NET. But
assuming you're putting the basic building-blocks together correctly, you
are unlikely to find some specific method in some specific .NET class that
performs so poorly it justifies writing your own version before you've
done some actual performance measurements to show that it's a signficant
part of whatever performance problem you may be experiencing.
How can I use a profiler ( e.g. RedGate ANTS Profiler ) to breakdown
relative performance of method calls inside giant iterations ? ( i.e.
implement 3 different algorithms and/or coding techniques and see which one
is taking the least time on avg per iteration )
"Peter Duniho" <NpOeStPeAdM@nn owslpianmk.comw rote in message
news:op.uboph6x 98jd0ej@petes-computer.local. ..
On Sat, 24 May 2008 17:11:32 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
>
>Hi Peter, and thanks for the response.
>>
>What about string.Replace( ) ... ?
>>
>Same answer ?
>
I would reply with basically the same answer for nearly every method in
the .NET Framework. Especially the part about not worrying about it until
you've proved it's a performance bottleneck.
>
There are certainly dumb, inefficient ways to do things in .NET. But
assuming you're putting the basic building-blocks together correctly, you
are unlikely to find some specific method in some specific .NET class that
performs so poorly it justifies writing your own version before you've
done some actual performance measurements to show that it's a signficant
part of whatever performance problem you may be experiencing.
>
Pete
On Sat, 24 May 2008 17:55:33 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
How can I use a profiler ( e.g. RedGate ANTS Profiler ) to breakdown
relative performance of method calls inside giant iterations ? ( i.e.
implement 3 different algorithms and/or coding techniques and see which
one is taking the least time on avg per iteration )
I admit, I cannot advise you on the use of any specific profiler. It's
been many years since I needed to do intensive profiling work, and surely
the tools have changed a lot since then.
But I'm sure they still offer the same basic options: sampling vs.
instrumented, and using either method they will report things like
percentage and actual time spent in a specific method. This information
will allow you to see whether in fact improving the speed of the
String.Replace( ) method would help your program run faster.
When I need to measure the speed of things today, it's usually pretty
simply stuff, and I just use the Stopwatch class to find out how much time
specific sections of my code are taking.
On May 25, 1:11 am, "John A Grandy" <johnagrandy@ g-mail-dot-com>
wrote:
Hi Peter, and thanks for the response.
>
What about string.Replace( ) ... ?
>
Same answer ?
Modulo the observation that StringBuilder.R eplace may be a better fit
for your application (if you do multiple replaces on the same string,
then string.Replace will generate lots of different strings, whereas
the StringBuilder one won't), almost certainly yes.
It does depend what your application is. My guess is that the
framework is optimized for Split/Replace on strings a few k's long.
If your data is 100 MBytes, there may be other operations (like
splitting in place), that would be worthwhile.
On Sat, 24 May 2008 16:37:31 -0700, John A Grandy
<johnagrandy@ g-mail-dot-comwrote:
>
Is string.Split() performant to a degree that there's no point in trying
to write code to improve on its performance ?
>
I would expect so. But if it's important to you, you can always test its
performance yourself to determine for sure.
>
I certainly wouldn't waste any time writing my own implementation until
I'd proved that my program was spending an inordinate amount of time in
the String.Split() method.
Comment