About
With the version 1.25, this performance issue has been resolved by using a generic syntax plugin that captures all components to overcome the dokuwiki parser limitations.
When installing combo, people may see a degradation in performance during the initial rendering of a page.
This page explains why.
Note of caution
The measurements have been made on a development laptop with:
- Apache 2.4
- Without FastCGI
- On Windows
- With Php 7.2.4
- And Xdebug installed (debug instruction adds time)
On a production Linux server, the latency measured is in the second range.
Why ?
Why do we get extra execution time after installing combo.
Large Number of syntax components
The one reason for the degradation is due to the parser.
The execution time of the parser is a linear function of the number of syntax component.
Combo adds 95 components.
The more syntax, the more the parser takes time to build.
In this snapshot, we can see that for a parsing (get_instructions), the process runs for 9 seconds where:
- the parser build takes 6 seconds (connect)
- the actual parse takes 2.5 second
No parse tree
The second reason is that simple and still complex syntax components need to know where they are, in the page.
For instance: the combo heading may be:
- a outline heading that will be found in the toc
- or just a component heading
How does it know this fact?
It checks if it is inside a component or not (in other words, if it has a parent)
And unfortunately, this functionality is not embedded natively in DokuWiki.
- The parse tree is not a tree but a list (an array)
- We can't jump to the parent, we need to read through the list
- When deleting, we delete in a list, we lost the internal array pointer, meaning we need to read the whole array to position the pointer back.
- In the render function, we don't get the parse tree at all, we can't, therefore, adapt the output to the parent, we need to do that in the parse step (first request)
The below snapshot shows that moving in the parse tree (called callstack in combo), takes up 1/3 of the execution time (3secs over 9)
Slot
Combo offers slot functionality that the user can modify on the fly (header, footer, …).
This functionality means that the parser needs to be used, adding execution time to the first request.
Works in Progress and Solution
To solve this problem, we are working on the … parser.
By order of priority, we have:
- registering only one component that will dispatch to all marki components
- creating a parser with a parse tree
- going to a language that is not a script (CGI), such as node so that the parser is created at start time and not each time.
Data Profiling
If you want to check, below are requests from the edit page that have been profiled.
You can read them with any Xdebug Profile Reader
You can see that the more execution, the more time.
| Plugin | Configuration | Profile file | Server Time | Profile File Size (kb) |
|---|---|---|---|---|
| None | without cache | cachegrind.out.1671625103-D__dokuwiki_doku_php | 880ms | 5941 |
| Combo | without cache, first request | cachegrind.out.1671625269-D__dokuwiki_doku_php | 7sec | 43734 |
| Combo | with cache, second request | cachegrind.out.1671625714-D__dokuwiki_doku_php | 976 after upstart | 3543 |
| Combo / strap | without cache, first request | cachegrind.out.1671625904-D__dokuwiki_doku_php | 10 second | 70652 |
| Combo / strap | with cache, second request | cachegrind.out.1671626765-D__dokuwiki_doku_php | 822ms | 3974 |
The files are available on this link