Performance Quiz #3

re: Performance Quiz #3

Marco Russo — Sat, 26 Jun 2004 00:28:00 GMT

The RAD parser creates 16 new string for each line. If you have 2,500 lines, there are 40,000 new strings created that has to be collected by GC. Not to count the 2,5000 arrays you creates just to feed the foreach loop.
In terms of speed, there are possibly two bottlenecks: the String.Split method and the Int32.Parse method. I hadn't checked with a profiler how much it is. GC isn't a heavy load on my tests.
Anyway, I prefer to use the RAD source code unless the performance impact of the parser become a real bottleneck in a real application.... :-)

Parser Differences

Rico Mariani — Sat, 26 Jun 2004 03:02:00 GMT

Some people have pointed out that the two parsers don't parse exactly the same thing. This is of course correct -- the 2nd parser is somewhat simplified compared to the first. I did this largely in the interest of keeping the source code small and somewhat understandable.

One of the things I plan to discuss in the analysis is the complexity/correctness part of the trade-off.

However it is worth noting that tightening or widening the accepted strings of the 2nd parser would not materially affect its performance characteristics so for purposes of this analysis what is there is fairly representantive.

re: Performance Quiz #3

Ryan Lamansky (Kardax) — Tue, 29 Jun 2004 00:08:00 GMT

It's also worth mentioning that the second approach is almost free of function calls.

One of the important performance risks of calling into an API (particularly a closed-source one) is that you have no idea what it does to get your results, but you can have some assurance that it's not specially optimized for what you're doing.

Since the whole "problem" is closed, the JIT could (theoretically) optimize all the extra stuff away, but it'll be a long time before we see a JIT that powerful :)

Performance Quiz #3 -- Solution

Rico Mariani's WebLog — Wed, 30 Jun 2004 01:11:00 GMT