When to lazy-load your plugin code to help CGI performance

Background

For best performance, Foswiki should be configured to use a persistent perl environment (see FastCGIEngineContrib or ModPerlEngineContrib). However, for large plugins, it's generally considered good practice to minimise compile times for Foswiki users running with plain old CGI where possible.

This involves splitting the main plugin code away from the plugin package. The plugin package will contain a minimum of code which loads the plugin core package(s) only as required.

This will benefit users running Foswiki under plain old CGI for any request where the plugin in question is not actually used.

Problem

When comparing a lazy-loaded plugin vs monolithic plugin, there is a performance penalty on any request that requires the plugin. This tip tries to document some numbers that might help a plugin author trying to decide if it's worth splitting up their plugin so that the main code is lazy-loaded.

Known Uses

• BibliographyPlugin
• ControlWikiWordPlugin
• FlexFormPlugin
• ImageGalleryPlugin

TwistyPlugin

TwistyPlugin.pm has 326 code lines (according to sloccount). As an experiment, it was split into 70/327 code lines between the plugin package and Core.pm.

To do the timings, the Foswiki view script was run from the command line using time.

Normal request

time  ./view -topic System.WebHome > /dev/null

Twisty request

time  ./view -topic System.TwistyPlugin > /dev/null

Tests were run >50 times for each configuration on a 1.6GHz Pentium-M machine. Run results were averaged into the numbers below

Version	Normal Request	Request with Twisty macro
distro:3ed07b3c2278	685.0ms	846.2ms
distro:47f14333dbff (Lazy-loaded)	679.1ms	852.1ms

-- PaulHarvey - 15 Aug 2010

Discussion