Make All Static Regex's Readonly and Compiled about markdownsharp HOT 9 CLOSED

As you noticed, it's a bad idea to blindly compile all the regexes.

I already made a pass with ANTS Performance profiler and compiled just the 
regexes
that the profiler told me were expensive. This provides the best blend of short 
and
long performance with almost no compromises.

That's the proper solution IMO -- just compile the ones that actually take the
longest. If you compile them all, short performance suffers too much. And short
performance is important; for example, the average Stack Overflow post size is 
just
over 1000 characters.

Seems odd it would just be short strings. Let me test tonight and see if the 
Regex compile is sililiar to the 
asp.net load time where it only occurs on first hit. Seems like a logical jump 
since it is first hit in the tests. 
Unless you have tried this before. 

well, you could increase the # of short benchmark iterations to something like 
20k or
50k -- that would simulate lots of calls with initial compilation. Though, I 
suspect
the results will be similar. The time taken does go down about 0.10 ms per call 
when
I increase the short benchmark run size from 1k to 20k --

{{{
input string length: 475
performed 20000 iterations in 17125 (0.85625 ms per iteration)
input string length: 2356
performed 500 iterations in 1978 (3.956 ms per iteration)
input string length: 27737
performed 100 iterations in 5171 (51.71 ms per iteration)
}}}

some comparisons of short performance, varying # of iterations...

{{{
input string length: 475
performed 1000 iterations in 977    (0.977 ms per iteration)

input string length: 475
performed 2000 iterations in 1886   (0.943 ms per iteration)

input string length: 475
performed 4000 iterations in 3578   (0.895 ms per iteration)

input string length: 475
performed 8000 iterations in 7058   (0.882 ms per iteration)

input string length: 475
performed 16000 iterations in 13899 (0.869 ms per iteration)

input string length: 475
performed 32000 iterations in 27995 (0.875 ms per iteration)
}}}

[deleted comment]

I updated from the latest SVN changes and here are the numbers I am seeing on 
my 
machine now with the following patch:

patched:
{{{
input string length: 475
performed 1000 iterations in 1047 (1.047 ms per iteration)
input string length: 2356
performed 500 iterations in 2325 (4.65 ms per iteration)
input string length: 27737
performed 100 iterations in 6583 (65.83 ms per iteration)
}}}

un-patched:
{{{
input string length: 475
performed 1000 iterations in 1202 (1.202 ms per iteration)
input string length: 2356
performed 500 iterations in 2733 (5.466 ms per iteration)
input string length: 27737
performed 100 iterations in 7411 (74.11 ms per iteration)
}}}

Seems to be getting better performance numbers with the re-factored testing 
framework 
that you included.

agreed, I can verify it's faster for me too now!

Must have something to do with the bugfixes in the previous revisions.. I'll 
accept
this change since it is faster in all 3 benchmark test cases now.

oh and here are my before and after benchmarks, too:

before:

input string length: 475
performed 1000 iterations in 847 (0.847 ms per iteration)
input string length: 2356
performed 500 iterations in 1956 (3.912 ms per iteration)
input string length: 27737
performed 100 iterations in 5184 (51.84 ms per iteration)

after:

input string length: 475
performed 1000 iterations in 682 (0.682 ms per iteration)
input string length: 2356
performed 500 iterations in 1617 (3.234 ms per iteration)
input string length: 27737
performed 100 iterations in 4428 (44.28 ms per iteration)