Re: [VOTES] Text_Wiki

Hi, Lukas,

Well your approach sounds well thought out. I don't have an immediate need for it but generally +1 from me. I have only read the proposal itself.

OK, so I'm at +1 then. Woohoo! ;-)

However I wonder how the performance is with such a flexible system. Then again I am not sure how relevant this is for a Wiki class.

I was concerned with performance, too. I originally figured that the performance would suffer by as much as 100% from a monolithic parser (i.e., twice as slow). It turns out that the performance reduction is more along the lines of only 10 to 15 percent slower than the fastest parsers, although it's hard to say for certain because I have modified some rules from the source Wiki parsers. With some parsers (e.g., WikkiTikkiTavi), they loop through every line in the source and apply each rule to the current line. That does not scale well; if there are 15 rules, each added line means an additional 15 iterations in the loop, so processing speed diminishes dramatically as the source text gets longer. Text_Wiki goes as fast as the Tavi parser for short pages, and goes faster than Tavi as the pages get longer. Other parsers (e.g., phpWiki, coWiki, et. al.) run through each rule and apply it to the source text in one pass; that means there is at most one loop iteration per rule. This is a much faster (although slightly more obscure, what with regex syntax) way of parsing. Text_Wiki runs about 10 to 15 percent slower than these kinds of parsers. I think this is because of the loading of rule class files, but there may be other issues I am missing (e.g., inefficient regex construction on my part). E.g., the Text_Wiki/docs/SamplePage.wiki.txt file transforms in about .24 seconds on an OpenBSD P3/700 with 512M using PHP 4.2.3 via Apache 1.3.26. -- Paul M. Jones Savant: the simple alternative to Smarty. http://phpsavant.com/