[pmwiki-users] MarkupToHTML optimisation

[Patrick R. Michaud]

On Thu, Jan 04, 2007 at 01:28:20AM -0600, JB wrote:
> This post claims it will improve pmwiki performance by 25%.
> 
>    http://article.gmane.org/gmane.comp.web.wiki.pmwiki.devel/43/match=
>
> Could this be made into recipe?
> Is there any reason this should not be used?
> Could this be put into the main distribution?

The claim of a 25% performance improvement in PmWiki is highly
misleading -- IIRC the author based that measurement on a site
that was using the WikiSmileys recipe with over 100+ smileys,
resulting in several hundred markup rules (one markup rule for
each smiley).  In that particular instance the performance was
improved by 25%.

On a standard PmWiki site one would see very little speedup 
from the patch  -- I suspect the actual improvement would be 
less than 5%, and because it adds additional processing to the
markup rule loops the net effect may actually be to make things
slower than they currently are.

The correct solution is to rewrite the WikiSmiley recipe to
use a single rule for all smileys, instead of a separate
rule for each.  For sites running WikiSmiley this would
improve performance far more than the proposed change does --
probably on the order of 50%.  (If there are a lot of
people running WikiSmiley that want this particular change,
I'll write it.)

Lastly, there is a potential downside to the patch in that
calling PHP's preg_replace() function with an array of patterns,
as this patch does, allocates memory for each search/replace
but doesn't free any of the allocated memory until after all
of the patterns in the array have been processed.  This could
pose a problem for sites that have memory restrictions and/or
large pages (and yes, this has occurred in at least one
instance).

I may still use some of the ideas proposed by the patch in the
core, but I don't think the performance improvement will be
significant.

Pm