<P/>
The purpose of this section is to show how to use &GAP;'s line-by-line profiling / code coverage. For this, you need &GAP; 4.10 or newer.
<P/>
Do you just care which lines of code are executed? Then you should switch to the coverage guide (these two guides are very similar!)
<P/>
We will start with a quick guide to profiling, with some brief comments. We will explain later how to do these things in greater depth!
<P/>
Let's start with some code we want to profile. Here I am going to profile the function f given below, and use a group from the AtlasRep package.
<P/>
<Listing><![CDATA[
LoadPackage("atlasrep");
a := AtlasGroup("U6(2)", NrMovedPoints, 12474);
b := a^(1,2,3);
f := function() Intersection(a,b); end;
]]></Listing>
<P/>
Firstly, we will record a profile of the function <C>f</C>:
<P/>
<Listing><![CDATA[
# Code between ProfileLineByLine and UnprofileLineByLine is recorded
# to a file output.gz
ProfileLineByLine("output.gz"); f(); UnprofileLineByLine();
]]></Listing>
<P/>
You should write this all on a single line in &GAP;, as profiling records the real time spent executing code, so time spent typing commands will be counted.
<P/>
This creates a file called <F>output.gz</F>, which stores the result of running <C>f</C>. Now we want to turn that into a nice output. This requires loading the &profiling; package, like this:
<P/>
<Listing><![CDATA[
LoadPackage("profiling");
OutputAnnotatedCodeCoverageFiles("output.gz", "outdir");
]]></Listing>
<P/>
If loading the &profiling; package produces errors, make sure you have compiled both the &profiling; and <Package>IO</Package> packages.
<P/>
<Ref Func="OutputAnnotatedCodeCoverageFiles"/> reads the previously created <F>output.gz</F> and produces HTML output into the directory <F>outdir</F>.
<P/>
You must view the result of your profiling in a web-browser outside of &GAP;. Open <F>index.html</F> from the <F>outdir</F> directory in the web browser of your choice to see what happened.
<P/>
At the very top is a link to a flame graph. These give a quick overview of which functions took the most time. Functions are stacked, so lower functions call higher functions.
<P/>
From this graph we can see that <C>f</C> called <Ref Func="Intersection" BookName="ref"/>, which called the function <C>Intersection2 perm groups</C> near line 2950 in <F>stbcbckt.gi</F>. This function spent most of its time in <C>PartitionBacktrack</C>, and a little time in <C>Stabilizer</C>.
<P/>
Whenever you generate a profile which contains timing information, a flame graph link will be show on the first page of your generated profile!
<P/>
</Section>
<P/>
<List>
<Item>
<Ref Func="ProfileLineByLine" BookName="ref"/> records the wall time (also known as clock time) that occurs between <Ref Func="ProfileLineByLine" BookName="ref"/> and the next <Ref Func="UnprofileLineByLine" BookName="ref"/>. This is why we start profiling, run our code, and then stop profiling all on a single line.
</Item>
</List>
<P/>
<List>
<Item>
If you want to profile how long everything in &GAP; takes, including the startup, then you can do this by giving the command line option <C>--prof filename</C> when starting &GAP;. This is equivalent to &GAP; calling <C>ProfileLineByLine("filename");</C> before loading any of the standard library (obviously, give your own filename).
</Item>
</List>
<P/>
<List>
<Item>
Giving your output file the <C>gz</C> extension makes &GAP; automatically compress the file. This is a great idea, because the files can get very big otherwise! Even then, the files can grow quite large very quickly, keep an eye on them.
</Item>
</List>
<P/>
<List>
<Item>
<Ref Func="ProfileLineByLine" BookName="ref"/> takes an optional second argument which is a record, which can set some configuration options. Here are some of the options:
</Item>
</List>
<P/>
<List>
<Item>
<C>wallTime</C>: Boolean (defaults to <K>true</K>). Sets if time should be measured using wall-clock time (true) or CPU time (false). Measuring CPU-time has a higher overhead, so avoid it if at all possible!
</Item>
</List>
<P/>
<List>
<Item>
<C>resolution</C>: Integer (defaults to <C>0</C>). By default &GAP; will record a trace of all executed code. When non-zero, &GAP; instead samples which piece of code is being executed every <C>resolution</C> nanoseconds. Setting this to a non-zero value improves performance and produces smaller traces, at the cost of accuracy. &GAP; will still accurately record which statements are executed at least once. This is mainly useful when you wish to consider very long-running code.
</Item>
</List>
<P/>
</Section>
<P/>
Sometimes you will have code that just runs too long to easily profile line-by-line. You can profile this in &GAP;'s older function-based profiler. You can read more about this profiler in &GAP;'s documentation (<Ref Sect="Profiling" BookName="ref"/>), but here is a quick example to get you going!
<P/>
<Listing><![CDATA[
ProfileGlobalFunctions(true);
ProfileOperationsAndMethods(true);
f();
ProfileGlobalFunctions(false);
ProfileOperationsAndMethods(false);
DisplayProfile();
]]></Listing>
</Section>
</Chapter>
¤ Dauer der Verarbeitung: 0.15 Sekunden
(vorverarbeitet)
¤
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung ist noch experimentell.
