You’re absolutely right. There are some performance issues.
They are in the block handling part of the parser. I have not focused on performance, but have tried to make an extensible design. Now that all the tests pass, I will look at improving the block handling, and hopefully improve performance and extensibility.
The race is on! A healthy competition is never a bad thing. Although we should probably get some documents more suited for the benchmark.
CommonMark.NET 0.1.2 15 ms 23%
CommonMark.NET 0.1.0 56 ms 83%
CommonMarkSharp 0.1.0 276 ms 409%
MarkdownSharp 1.13 56 ms 83% (might not conform to CommonMark specification)
MarkdownDeep 1.5 8 ms 11% (might not conform to CommonMark specification)
Baseline 67 ms 100% (used to compare results on different machines)
I honestly think the spec is a very good choice. It covers all the syntax elements. However it could be interesting to see how they perform with other documents.
BTW
You might like to look at the test project for CommonMarkSharp. It creates unit tests for each spec in spec.txt using a T4 template (Specs.tt), so they can be run from the test explorer. The spec is retrieved using bower, so getting the newest spec is just a question of calling:
bower update
And running custom tools on Specs.tt.
This should be easy to adjust for your project, if you want.