Page MenuHomePhabricator

Why is invoking/running this specific module slow?
Open, Needs TriagePublic

Description

For improved functionality, a template was invoking a new module, Module:Code de liste décalable, but I had to remove this module invocation, after I noticed in the "NewPP report" that it increased the template execution time from 0.3 ms to 3 ms, approximately. As the template is usually used many times, and in most of the articles, this resulted in a noticeably increased rendering time.

Though, the Lua code itself is very fast. In most cases, all it does is a plaintext string.find(). Even if the input string may be (moderately) large, on my local machine the Lua code takes something like 1 µs.

For comparison, we have some frequently used templates on frwiki, {{Date}} and {{Unité}}, that have an underlying module (Module:Date and Module:Unité respectively), and although they are much more complex, I'm considering that every inclusion of these templates takes about 1 ms, as a rule of thumb. 80% of that millisecond being the invocation setup overhead, and 20% the actual Lua code (see T357199, on this matter).

Thus, I don't understand why the module I mentionned at the beginning, although it has an expectedly fast code, takes as much as 3 ms…

Event Timeline

I did a simple test, though not in MediaWiki environment, and found out that simply

return value:gsub( '\n[ \t]+%*', '\n*' )

without any string.find() will be about 27% faster.

Further, getting rid of value will save about one percent:

return frame.args [1]:gsub( '\n[ \t]+%*', '\n*' )

I think your question contains the answer. Simple modules do not justify the overhead of invoking them. Modules should be used when wiki markup with parser functions is either unable to do the task at all, or is esoteric and slow. Which takes us back to T357199.

As the functionality was new, in 99.999% of existing uses there was no replacement to do actually. Thus, I wanted to optimize these cases the most possible, and the plaintext string.find() is a prefilter to rule them out as fast as possible.

Though, execution time of the Lua code alone (1 µs) and of the entire template (3 ms) aren't even on the same order of magnitude. So the performance issue shouldn't be in the Lua code itself, but in the invoke overhead.

But I don't understand why this module in particular has such a large overhead, compared to other modules.