Runtime and number of calls for designated functions, methods, or pieces of code. Optionally output nice report.
Measures how often designated functions, methods, or pieces of code are executed and what their runtime is. Optionally prints a nice report to the screen, although the raw data is available for further processing as well.
- Mark parts of the code that should be monitored with the provided context manager or decorators.
- Tell your program to output the report or provide you the data when it’s done.
- Run your program.
How to designate code that should be monitored.
A free-standing piece of code.
from aeon import timer with timer('my measurement'): # do stuff here... # to assign the measurement to a specific group with timer('my measurement', 'general frobnication'): # do stuff here
from aeon import timer @timer def my_function(): pass
from aeon import timer class Foo(object): @timer.method def bar(self): pass
How to see the report.
from aeon import timer print timer.report() print timer # equivalent
You can instantiate your own timer if you want to, in case you want to use several in parallel.
from aeon import Timer my_timer= Timer() with my_timer('my_measurement'): pass # or with my_timer('my_measurement', 'my_group'): pass @my_timer def foo(): pass class Foo(object): @my_timer.method def bar(self): pass
The timer object can be queried for specific measurements or the data with which it generates the report.
Also, nothing prevents you from using the Measurement class on its own:
from aeon import Measurement m = Measurement() for i in xrange(100): m.start() # stuff happens here m.stop() assert m.calls == 100 print m.total_runtime, m.time_per_call
Installation is easy as:
$ sudo pip install aeon
The code has originally been used in a computational physics project where the typical runtime distribution is very dependent on the problem at hand. It has proven itself useful for giving a feel for where time is spent during computation and quickly showing when parts of code went on a riot. In fact, in that project, it is enabled in production since the overhead is low.
What sets it apart is the possibility to monitor only specific parts of the code and optionally have these parts logically grouped (by default, it will use the class or module names).
There are better alternatives for proper benchmarking, like cProfile.