Timing the time it takes to parse timePart I
time to read 2 min | 344 words

This is a small part from a larger benchmark that we run:

 

The index in question is using a DateTime field, and as you can see, quite a lot of time is spent in translating that. 50% of our time, in fact. That is… not so nice.

The question now is why we do it? Well, let us look at the code:

image

Here we can see several things, first, there is the small issue with us allocating the string to check if it is a date, but that isn’t where the money is. That is located in the TryParseExact.

This method is actually quite impressive. Given a pattern, it parses the pattern, then it parse the provided string. And if we weren’t calling it hundreds of thousands of times, I’m sure that it wouldn’t be an issue.  But we are, so we are left with writing our own routine to do this in a hard coded manner.

I built the following benchmark to test this out:

image

As you can see, this is pretty much identical to our code, and should tell us how good we are. Here are the benchmark results:

Method

Platform

Jit

Toolchain

Runtime

Median

StdDev

ParseDateTime

X64

RyuJit

Host

Host

2,458.2915 ns

102.7071 ns

ParseDateTime

X86

Host

Clr

Clr

2,506.7353 ns

142.7946 ns

ParseDateTime

X86

LegacyJit

Host

Host

2,443.4806 ns

51.4903 ns

In my next post, I’ll show what I came up with that can beat this.

Tweet Share Share 2 comments
Tags:

More posts in "Timing the time it takes to parse time" series:

  1. (11 Oct 2016) Part II
  2. (10 Oct 2016) Part I