For best performance, Foswiki should be configured to use a persistent perl environment (see FastCGIEngineContrib
). 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.
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.
.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
script was run from the command line using time
time ./view -topic System.WebHome > /dev/null
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
- 15 Aug 2010