On 8/28/07, Michel Fortin <[EMAIL PROTECTED]> wrote: > I'm not quite sure what's the culprit in Markdown.pl, although I > suspect the overuse of the HTML block parser to hash Markdown- > generated markup is part of it. That's one thing I've removed in the > many architectural changes PHP Markdown passed through since version > 1.0.1d.
I found a couple of problems with Markdown.pl when I ported it to JavaScript, but I don't know whether they're enough to explain the non-linear slowdown we're seeing. Off the top of my head, there's the MD5 stuff (which was obviously meant to be temporary) and an exploding regexp in _Detab (which can be fixed with \G). My guess is that once those are fixed, the other problems will become obvious with a little testing. > Sure. 49 seconds (for the 176 Kb document). Oh, and parsing the > double-sized document (352 Kb) took 289 seconds (almost 5 minutes!). > That's clearly not linear. So even if we optimized the rest of Markdown.pl so that it handled the TextMate manual in 1.5 seconds, we'd still be stuck at around 33.5 seconds -- 95% of which is the new HTML block parser. Looks like any optimization of Markdown.pl would have to start with a look at the Text::Balanced stuff. John Fraser _______________________________________________ Markdown-Discuss mailing list [email protected] http://six.pairlist.net/mailman/listinfo/markdown-discuss
