It takes a very, very long time to open the template dialog for larger templates or multi-part transclusions with many templates. A trivial example with 200 undocumented parameters looks like this:
{{example
|p0=0
|p1=1
|p2=2
|p3=3
…
|p196=196
|p197=197
|p198=198
|p199=199
}}I did a quick profile run to possibly identify some low-hanging fruits. This is how a flame graph for said 200 parameter template looks like:
There are 3 big chunks in this graph:
- (~500ms) MWTemplateDialog.onAddParameter() is called individually for each parameter, 200 times. This creates the corresponding MWParameterPage and calls .addPages(), 200 times. There is no single bottleneck. It's just so much to do. Still there are some ideas how this could be optimized:
- Change the relevant events so that .addPages() is only called a single time, with an array of all 200 parameters.
- Initialize a multi-part transclusion in a collapsed state where only the top-level template names are visible, but no parameters. The MWParameterPages are created when the user clicks the template name the first time.
- …?
- (~400ms) TextInputWidget.installParentChangeDetector() is called 200 times.
- What is this for? Can we optimize the existing code, e.g. running it on an array of elements instead of individually for each element (similar to above)? Can we delay the call even more?
- …?
- (~300ms) MWExpandableContentElement.updateSize() is called 200 times.
Must be skipped when it's not needed anyway.Done.- When it's needed, can we delay it somehow? Can we optimize the code, e.g. to do much cheaper calculations when the text is known to be short?
- …?
