Module:Timing/doc: Difference between revisions

Revision as of 11:33, 19 January 2016

Latest revision as of 22:15, 2 May 2023

(6 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 (iei.e. on a single function).

''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 limitslot 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 &times; 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 15:

=== Testing a plain function ===

For example, assume we open a page [[Module:HelloWorldExample]], then we can write a call to profile the function p.hello(). The code in the page looks something like the example below, but local versions may be a little different. (At ''nowiki'' a similar code is at [[w:no:Module:HelloWorld2]].)

The following code is a stripped -down version of [[Module:HelloWorldExample]]. See the page for a full version.

<sourcesyntaxhighlight lang="Lualua">

my_objectlocal p = {};

my_objectp.hello = function( frame )

local str = "Hello World!"

return str

end

return my_object p

</syntaxhighlight>

</source>

Access to this code will be through a generic ''p'' in the debug console. Assuming the previous code the profiler can be called as

<sourcesyntaxhighlight lang="Lualua">

=require 'Module:Timing'(p.hello)

</syntaxhighlight>

</source>

A call like that produced for the same type of module a report like the following at enwiki

Line 47:

</pre>

In this the important information is <ttsamp>Each call was running for about 8.5120000000022E-9 seconds</ttsamp>. This says how long the function actually run.

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 ===

Line 57:

A common example on how to pass in an argument is how to do this for the current frame

<sourcesyntaxhighlight lang="Lualua">

=require 'Module:Timing'(p.hello, mw.getCurrentFrame())

</syntaxhighlight>

</source>

This produce the following output

Line 83:

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

<sourcesyntaxhighlight lang="Lualua">

function wrap() return p.hello(mw.getCurrentFrame()) end

=require 'Module:Timing'(wrap)

</syntaxhighlight>

</source>

A call sequence like that produced the following output

Line 105:

An alternate form with an anonymous function is

<sourcesyntaxhighlight lang="Lualua">

=require 'Module:Timing'(function() return p.hello(mw.getCurrentFrame()) end)

</syntaxhighlight>

</source>

In general you should precompute as much as possible to avoid unnecessary computations inside the loop, like this

<sourcesyntaxhighlight lang="Lualua">

my_frame=mw.getCurrentFrame()

=require 'Module:Timing'(function() return p.hello(my_frame) end)

</syntaxhighlight>

</source>

====Wrapper in the module====

Sometimes it is better to put the wrapper in the module itself

<sourcesyntaxhighlight lang="Lualua">

my_object = {};

Line 131:

return my_object

</syntaxhighlight>

</source>

That produced the following output

Line 148:

In general you should precompute as much as possible to avoid unnecessary computations inside the loop, like this

<sourcesyntaxhighlight lang="Lualua">

my_object = {};

Line 162:

return my_object

</syntaxhighlight>

</source>

===Testing in a sandboxed environment===

Line 169:

Sometimes it is better to put the wrapper in the module under inspection itself

<sourcesyntaxhighlight lang="Lualua">

local timing = require 'Module:Timing'

Line 184:

return my_object

</syntaxhighlight>

</source>

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

<sourcesyntaxhighlight lang="html5wikitext">

{{#invoke|HelloWorld|TIMING}}

</syntaxhighlight>

</source>

and we will have a timing report for the helper call in the module.

Line 211:

* [[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 occurencesoccurrences, which is not quite right''

<includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox||