char[] to DateTime

[Mark]

Is there a way to convert a char[] to a DateTime without first converting to
a string and using DateTime.Parse or ParseExact? I'm trying to reuse the
char[] which can be reused instead of converting to a string since string is
immutable and must be GC'ed. Please, I'm looking for a conversion between
an char[] to DateTime without intermediary step.

Thanks in advance

Mark

[Bruce Wood]

What kind of application are you writing that the construction of one
string and one GC is going to affect you that much?

By the way, char[] needs to be GC'd as well.

[Jon Skeet [C# MVP]]

Bruce Wood <br*******@canada.com> wrote:

What kind of application are you writing that the construction of one
string and one GC is going to affect you that much?
Agreed.
By the way, char[] needs to be GC'd as well.

Yes, but it can be changed and reused without creating a new object. I
once wrote a MIDP version of Tetris which, after starting up, didn't
create a single new object until you quit. Of course, that was in an
environment where it really, really mattered!

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mark <no*****@newsgroup.nospam> wrote:

Is there a way to convert a char[] to a DateTime without first converting to
a string and using DateTime.Parse or ParseExact? I'm trying to reuse the
char[] which can be reused instead of converting to a string since string is
immutable and must be GC'ed. Please, I'm looking for a conversion between
an char[] to DateTime without intermediary step.

As Bruce said, is it really likely to be a problem to have the string
garbage collected? So long as it stays in generation 0, it's very
unlikely to make much difference.

Of course, you *could* write your own parser for DateTime, and that may
be reasonable if you've got a fixed format - especially if it's one
which is very straightforward, like yyyyMMddHHmmss, but I would try to
get some performance data which shows the "normal" way to be a
bottleneck before resorting to things like that.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bill Butler]

"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