One efficiency problem in dokuwiki, especially on systems with shared hosting (so doku's php is less likely to be cached at any given moment), is the time it takes to read all the php files. This is worse when there are a lot of plugins.
- When a syntax plugin is installed, load it immediately.
- Look for calls to pattern functions (addSpecialPattern etc).
- Add those pattern-matchers to a seperate php file. This file contains the pattern
matchers for all installed syntax plugins.
- When doku is started, do not immediately load all syntax plugins. Instead, just load
the pattern matcher file. That way, you can put off loading plugins until you know
you need them.
Is this feasible for DokuWiki?
For the majority of requests to DokuWiki, the syntax plugins should not be loaded at all because all content is cached. I believe this optimization tries to optimize at the wrong place.
I'm happy to change my opinion when useful benchmarks are provided. For now, I close this.
That's only true on a frequently visited or very dense wiki (large number of average hits per page). On a wiki like mine, with a large number of pages, each of which is hit infrequently, pages are often not cached.
But I certainly understand that this is a difficult and bug-prone request, which is probably very low on the priority list compared to other optimizations.
Increase your cache parameter. It can be made 100 years without any undue ill effects. If other cache dependencies change - e.g. dokuwiki is updated, new plugins installed, configuration settings changed, internal link existence changes - dokuwiki is smart enough to rebuild the page.
In my particular case, I'm very limited in disk space, but I realize this is an uncommon issue. The optimization would help with page edits, particularly with plugins that allow in-place edits. But again, probably low on the priority list.