https://bugzilla.wikimedia.org/show_bug.cgi?id=45684
Robert Rohde <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Robert Rohde <[email protected]> --- I'm going to second this request. The current Lua timing system, which counts the time that the parser takes to expand parameters sent to Lua against the Lua run time will make it difficult to know whether Lua conversions will be effective for widely deployed templates. Consider a case of two complex templates: {{ templateA | ... }} and {{ templateB | ... }} Suppose that each takes 0.25 seconds under the current parser system. Then a construction like: {{ templateA | {{ templateB | ... }} }} will take about 0.5 seconds per iteration. If these are frequently used formatting templates, this combination might appear 60 times on a single page, leading to very long render times (i.e. > 30 seconds). Now we come along and find an easy Lua replacement for templateA: {{ #invoke: fastLua | A | ... }} That only take 0.01 seconds to execute in the typical case. Our combination case {{ #invoke: fastLua | A | {{ templateB | ... }} }} now ought to render the page nearly twice as fast. However, in practice we find that fastLua | A can't be deployed to any page that heavily uses this construction, because the Lua time limit is getting charged for the time it takes to expand it's parameter {{ templateB | ... }}, and after ~40 of those the entire Lua clock limit is gone. This happens even though the actual time spent on Lua operations was only 0.4 seconds. Hence, even though a fast solution can be found, the way the limits are constructed may make it impossible to deploy in some cases. Lua developers shouldn't have to worry about perverse cases like this. Slow downstream templates shouldn't be counted against Lua run times. There has already been at least one case of having to develop a workaround to accommodate existing pages for a scenario just like the one described above, and there are other examples where it would occur if the Lua code presently being developed were moved into the live templates. I've seen in use examples where getExpandedArgument consumes over 96% of Lua run time. To avoid such negative interactions, the natural solution is to stop charging Lua for the time the parser takes to generate the parameters being sent to Lua. The other alternative would be to remove the separate Lua clock and only rely on a full page rendering limit. Either way, I think we need something to be done to avoid this issue being a recurring problem during Lua conversions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
