Content deleted Content added
mNo edit summary |
|||
| (25 intermediate revisions by 5 users not shown) | |||
Line 1:
{{Module rating |beta<!-- Values: pre-alpha • alpha • beta • release • protected -- If a rating not needed/relevant, delete this template call -->}}
<!-- Categories go at the bottom of this page and interwikis go in Wikidata. -->
The purpose of this module is to provide a simple method to do timing analysis for [[w:en:performance tuning|performance tuning]] of Lua-functions, that is [[w:en:Profiling (computer programming)|profiling of functions]]. Usually measuring the duration of function calls is part of a larger effort to identify bottlenecks and problematic code. This is not a full-blown profiler, as it is not possible to do line-tracing (call-graph profiling) in the current set up. Its only purpose is to measure execution time (flat profiling), and to do this interactively from the debug console (
''As it is said several times in this text; the timing is not accurate and it should only be used as a coarse measure of the approximate run time and load of a function. Do not attempt to fine-tune a module to just fit into the maximum allowed time slot for a module, keep well below the limit!''
The timing analysis is called with an executable function, and optionally a count (size, default 100) of each test set and a number of such test sets (default 10). The total number of calls will be ''count × sets'' and gives the mean runtime for the function. The standard deviation is calculated from the number of ''sets'' and will only be a coarse estimate. If only run with a single set the standard deviation will go away, but even if it isn't measured the execution time will still vary.
Line 12 ⟶ 15:
=== Testing a plain function ===
For example, assume we open a page [[Module:
The following code is a stripped
<
local str = "Hello World!"
return str
end
return
</syntaxhighlight>
Access to this code will be through a generic ''p'' in the debug console. Assuming the previous code the profiler can be called as
<
=require 'Module:Timing'(p.hello)
</syntaxhighlight>
A call like that produced for the same type of module a report like the following at enwiki
<pre>
=require 'Module:Timing'(p.hello
Each call was running for about
Relative load is estimated to 1.0.
</pre>
In this the important information is <
Note that this function is very simple, and therefore the run time for the function gets close to the run time for the baseline. As a result, the run time for each set gets close to the standard deviation.
=== Testing with arguments ===
The test call can take additional arguments. It will pass those on unaltered to the function under test. Most important, they are ''not'' cloned, that is they are passed on as is, and therefore if the function under test alters them then errors will accumulate. This can happen for the types ''function'', ''table'', ''userdata'' and ''thread''. We don't use ''userdata'' and ''thread'' on Wikipedia. That leaves ''nil'', ''boolean'', ''number'' and ''string'' as passed by value and safe against changes.
Strings are really pass by reference, but they are immutable and has copy on write.
A common example on how to pass in an argument is how to do this for the current frame
<syntaxhighlight lang="lua">
=require 'Module:Timing'(p.hello, mw.getCurrentFrame())
</syntaxhighlight>
This produce the following output
<pre>
=require 'Module:Timing'(p.hello, mw.getCurrentFrame())
Each call was running for about 3.0e-09 seconds.
Mean runtime for each set was 3.0e-07 seconds,
with standard deviation of 2.0e-07 seconds,
minimum 4.8e-06, maximum 5.2e-06.
Total time spent was about 1.2e-04 seconds.
Relative load is estimated to 1.1.
</pre>
Using arguments like this does not impose very much additional load, and most of it can be factored out.
=== Testing with a wrapper function ===
If a call need
====Wrapper in the debugger ====
The wrapper function can de defined in the debugger, that is added in the text area for debugging. Add a separate function like the following
<
function wrap() return p.hello(mw.getCurrentFrame()) end
=require 'Module:Timing'(wrap)
</syntaxhighlight>
A call sequence like that produced the following output
Line 60 ⟶ 93:
function wrap() return p.hello(mw.getCurrentFrame()) end
=require 'Module:Timing'(wrap)
Each call was running for about
Relative load is estimated to 3.7.
</pre>
Note that the duration of the call is much higher than the bare function itself! The inspected function must be a bit heavy, otherwise the wrapper will dominate the result.
An alternate form with an anonymous function is
<
=require 'Module:Timing'(function() return p.hello(mw.getCurrentFrame()) end)
</syntaxhighlight>
In general you should precompute as much as possible to avoid unnecessary computations inside the loop, like this
Sometimes it is better to put the wrapper in the module under inspection itself▼
<syntaxhighlight lang="lua">
my_frame=mw.getCurrentFrame()
=require 'Module:Timing'(function() return p.hello(my_frame) end)
</syntaxhighlight>
====Wrapper in the module====
<
my_object = {};
Line 88 ⟶ 131:
return my_object
</syntaxhighlight>
That produced the following output
Line 94 ⟶ 137:
<pre>
=require 'Module:Timing'(p.wrap)
Each call was running for about 1.
Relative load is estimated to 4.0.
</pre>
Also this wrapper is quite heavy compared to the tested function itself.
In general you should precompute as much as possible to avoid unnecessary computations inside the loop, like this
▲The morale is; do not add wrappers to very simple functions, the numbers will be far off! ;)
<syntaxhighlight lang="lua">
my_object = {};
my_object.hello = function( frame )
local str = "Hello World!"
return str
end
my_object.frame = mw.getCurrentFrame()
my_object.wrap = function ()
return my_object.hello(my_object.frame)
end
return my_object
</syntaxhighlight>
===Testing in a sandboxed environment===
Line 110 ⟶ 169:
Sometimes it is better to put the wrapper in the module under inspection itself
<
local timing = require 'Module:Timing'
Line 125 ⟶ 184:
return my_object
</syntaxhighlight>
This can them be used in [[Special:TemplateSandbox]] with a prefix from [[Special:MyPage/sandbox]] and any "render page" we see fit for the purpose. Often we want a specific page though to get access to additional data like the Wikidata item. Fill inn an invoke-call for our helper function
<
{{#invoke|HelloWorld|TIMING}}
</syntaxhighlight>
and we will have a timing report for the helper call in the module.
Line 139 ⟶ 198:
Not sure if this is really useful, will be getting back to this.
==Note of advice==
Simple functions gets close to the baseline in run time and because of that will be very noisy. When calculating a mean we actually do a low-pass filtering, removing high frequency noise. Still there will be noise and the only way to avoid it is to make longer runs (larger sets and more sets). Take note of the maximum and minimum run time, if they are to far from each other, or the standard deviation gets large, then it is very likely that the load situation on the server makes it difficult to get good results.
Note that a function consisting of one or two lines can be just fractions slower than the baseline function, but add a few function calls and the load explodes.
If the function is very simple, use the timing info. If the function is rather complex, use the relative load info.
Do not trust the measurement if they seems fishy, do trust your instinct. Especially, do not use higher order functions without thorough investigation even if they look very promising on simple cases!
==See also==
* [[w:en:Average]] ''The code use an arithmetic mean''
* [[w:en:Standard deviation]] ''The code use variance and standard deviation''
* [[w:en:Sum of normally distributed random variables]] ''The code makes an assumption that delays are independent random
<includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox||
| |||