Idea: Register Plugin Handlers in initPlugin

The plugins API already has a TWiki::Func::registerTagHandler to make the variable call more efficient.

The current plugin implementation is discovering the plugin handlers one by one for each initialized plugin. We can improve the performance if we add a TWiki::Func::registerPluginHandlers that is called in a plugin's initPlugin, passing along all handlers the plugin needs. For example, registering and enabling preRenderingHandler is much faster than discovering the currently 18 plugin handlers one by one.

For compatibility, same discovery of handlers should be done for those plugins that do not call registerPluginHandlers.

-- Contributors: PeterThoeny - 03 Oct 2006

Discussion

Have you benchmarked this? Because I'd be very surprised if it made any difference.

Whoever wrote the code (Andrea?) did the sensible thing and made a foreach loop that iterates over each registrable handler for each plugin, and adds the handler to the list of handlers that will be called if it is found in the package for the plugin. The difference between this, and calling a handler registration in initPlugin, is I suspect very, very small.

-- CrawfordCurrie - 04 Oct 2006

After some experiments with Devel::DProf and Devel::SmallProf (both run from the command line) I thought that this would be an interesting candidate, too. And it may be that it still is worth to be pursued as an idea, though maybe not (only) from a performance point of view: Loading the plugins and initializing the handlers per discovery takes about 5% of the time with 17 plugins enabled. The exact figures will depend on topic, number of plugins enabled, and platform. However, almost all of that is loading, and only a small portion (<1%) is due to the discovery. This can be verified if you pre-load the plugin modules explicitly, hereby moving them out of TWiki::Plugin::BEGIN (or TWiki::Plugin::load, where they would be if loading wouldn't use use):

perl -d:DProf -MMyPlugin -MAnotherPlugin ...

But apart from that the idea of actively registering handlers struck my mind, for the following reasons:

1. Scale: The current discovery mechanism scales with the numbers of plugins enabled times the number of handlers implemented (including the deprecated ones). In every installation, both numbers will increase with time: New plugins are installed, but almost never disabled again, and a new release might bring new handlers, but never remove some. Since new plugins usually only register a few handlers, active registration will scale with the number of plugins only, regardless of the number of handlers.
2. Persistence: New plugins or new handlers don't pop out of thin air. Their number and identity is a matter of installation and configuration, but not a per-request issue. In a persistent interpreter you need to restart the web server for every newly installed or enabled plugin since the configuration file(s) are only read once per process, so there's no benefit to check for new handlers over and over again. There are several structures in TWiki which could be made persistent, and the handlers are one of them.
3. With a modified API one could replace the current registering of strings, which need to be string-evaled under no strict 'refs' in TWiki::Plugin::invoke, by a registering of coderefs (like in TWiki::Func::registerTagHandler).
4. Inheritance: The current mechanism of discovery by name does not permit "derived" plugins which inherit methods from a base plugin. Not a big issue, though, especially if performance is concerned, since inheritance is an "expensive" mechanism in Perl.

The first two points could be solved through another route if discovery is moved from request handling to a post-processing step of bin/configure, at the expense of a less robust error handling during web operation if a plugin module gets damaged. But I guess bin/configure needs to mature a bit before undergoing the next big change.

-- HaraldJoerg - 04 Oct 2006

Thanks Harald for the thorough analysis. Good arguments to introducing a register handler feature.

Crawford: My impression was that you do not favor a new PluginHandlerForContentMove for performance reasons, hence the idea to do something about it.

-- PeterThoeny - 04 Oct 2006

Similar topic: LetTopicKnowAboutWhichPluginsToApply.

-- PeterThoeny - 24 Dec 2006