Several days to save one minute. It reminds me of the Terence Parr motto:

As antlr creator Terence Parr says "Why Program by Hand in Five Days what You Can Spend Five Years of Your Life Automating?" Uh, yes, and in the rest of the talk he answers why automation is good. You didn't just stop at the title, did you?

See https://news.ycombinator.com/item?id=8293390 http://parrt.cs.usfca.edu/

I look forward to the automated optimizer :-)

Since at this point, making the code faster by few instructions could make a difference, have you considered using & instead of && in the condition?

It would save one conditional jump, which, depending on the distribution of the data, could be hard for the CPU to predict.

I am glad you mentioned the cost of maintainability and readability. For me personally those two factors are incredibly important. Even more so when you work in a company with a lot of developers. Personally, I felt the solution that was done in around 3 seconds was the happy midpoint. It was readable and maintainable both to a very high degree but saw a massive reduction in time taken to execute the code.

Probably more importantly, why are you comparing the first 12 bytes? As far as I can tell, that includes the first digit of the time, so if the date is the same, but the first digit of time isn't, you're unnecessarily using the slow path. This means that casting to short* instead of int* could help by increasing the fraction of cases that use the fast path.

Is this correct that most speed up was obtained with MemoryMappedFile.CreateFromFile thing? Can anyone explain what is this and how it works? I've read a little bit but still don't get why is it that fast, after all it has to read 276 Mb from disk and it does it under a second? How?

Another question: what would happen if file would be larger than ram size?

Memory-mapping a file takes advantage of the OS's virtual memory capabilities, so the OS handles the business of reading pages into memory and flushing/evicting those which are no longer needed. The size of physical RAM is largely irrelevant since only a part of the file is mapped at a time, but if RAM is too tight then the OS will have to page more often which will put more load on the IO subsystem.

The IO speed in this case is down to the use of a solid-state disk. 276MB would take rather longer to read from a conventional spinning disk.

To clarify, the main benefit of memory-mapping in this case (I think) is that it drastically reduces the number of syscalls and memory copies required to access the data.

Reading a typical stream:

1. OS reads from disk into a buffer.
2. Application library code requests data from OS, which involves copying from the OS buffer into the application's buffer (typically 4K for .NET buffered streams?). This also involves a syscall so it might cause a context switch.
3. Application copies from its buffer into smaller structures.

And that's assuming that the application is using a buffered stream. Otherwise, pretty much every tiny read could result in a syscall.

Reading a memmapped file effectively bypasses the second step, mapping the page read from disk directly into the application's memory space. By using unsafe code and dealing with the bytes in-place, we can skip the third step too.

Ok, thanks, that make more sense now. Also @Ayende just a check: I've found here that super fast speed might be because of windows cache: http://stackoverflow.com/questions/26456195/why-is-reading-from-a-memory-mapped-file-so-fast#comment41553531_26456195 Is this taken into account?

Even for ssd this looks too good to be true:

http://unix.stackexchange.com/questions/88796/are-these-throughput-numbers-typical-for-an-ssd

Oops, ignore the last comment, it seems that 600Mb\s for ssd on windows is possible...

It looks like your code is fast but incorrect.

Original article said:

The first value is the entry time, the second is the exit time and the third is the car id.

But line 22 of the Final Version code seems to swap start and end):

        public static void Parse(byte* buffer, out int id, out int duration)
        {
            duration = DiffTimesInSecond(buffer + 20, buffer); // <<< Line 22
            id = ParseInt(buffer + 40, 8);
        }

        private static int DiffTimesInSecond(byte* start, byte* end)
        {

I see that you're using the Trace mode of dotTrace to do your performance profiling. This adds overhead to each called method to track the number of calls and for "free" methods, like property getters and such, it adds a not-so-insignificant overhead. I wonder what your performance profile results would look like if you switched to sampling, would you see the same results?