Frequently Asked Questions

General Obtaining GAP Installation Hardware/OS Usage Complaints Computing with GAP Programming GAP

5. Usage hints

5.8: When I use time or Runtime() or the profiler to determine how long a piece of GAP code takes, the answers can vary significantly. Why is this?

There are a number of possible reasons for this:

• 1. For some calculations, GAP actually uses randomized algorithms (although, unless you choose otherwise, the results produced are always checked). In these cases, the algorithm may be more or less "lucky" and take a shorter or longer time accordingly. You can usually avoid this variation by setting the random seed to a standard value before each test, using RANDOM_SEED(1).
• 2. Garbage collection. The GAP memory manager runs when the system runs out of free memory and can take significant time. To standardise when this happens, run GASMAN("collect") before each test.
• 3. The granularity of the underlying OS timing function being used is at best 1ms, sometimes courser, so a test which takes 0,1 or 2 ms per run could represent a calculation that takes about 1ms and may cross anywhere between 0 and 2 clock ticks without more than a small variation in how long it takes.
• 4. The method cache. The GAP method selection system caches the last few methods that were used for each operation. The cost of a cache miss is considerable.
• 5. The CPU cache. If the relevant parts of the GAP interpreter and/or of the workspace are in CPU cache when the test starts, this will save some time.

Also note that accessing, especially updating, global variables is significantly slower than local ones.

As described on the page Packages/Contrib/contrib.html there are links timers.g and README.timers to files containing and describing simple GAP routines useful for measuring the run-time of GAP operations which are too fast for the built-in methods of measurement.