"Bruce Wood" <br*******@canada.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I'm impressed that you've profiled it, but surprised at the results.
All of that disk I/O and the program is hung up in the CPU? Oh well,
profilers don't lie.
If DateTime.Parse() is a hot spot, my first question would be whether
your dates and times are in a consistent format? If they are, I would
write my own parse routine to read them directly out of the char[]
array. DateTime.Parse() is probably slow because it has to cope with
multiple input formats, not to mention internationalization concerns.
If you know, for example, that all of your dates are MM/DD/YY hh:mm:ss,
or all YYYY-MM-DD hh:mm:ss, or can even whittle it down to two or three
possible formats, writing your own (specific) routine would probably
speed things up considerably.
I ran across this exact situation a few years ago.
I was processing transaction data in a loop.
I determined that DateTime.Parse was the bottleneck.
Since the DateTime format was fixed in the incoming data I parsed it myself
and used
public DateTime(int year, int month, int day, int hour, int minute, int
second)
I don't remember the exact speed increase that I got, but it was
substantial.
Say from 1-2k/sec up to 5-10k/sec.
Now, the actual application only averaged ~100 trans/sec.
You could argue that the speed increase was irrelevant, but that is not
true.
The data came in in batches, so it was processed in ~1/3 the time.
And, my application spent more time sleeping instead of burning CPU cycles
so other apps could be run on the same box.
In my code I put a big comment explaining WHY I was doing this, so that the
chances were reduced of somebody FIXING my code.
Bill Butler