Latest commit 2b781f8 Aug 2, 2017 @eric-wieser eric-wieser committed with charris MAINT/DOC: Use builtin when np.{x} is builtins.{x}.
This is the case for x in {int, bool, str, float, complex, object}.
Using the np.{x} version is deceptive as it suggests that there is a
difference. This change doesn't affect any external behaviour. The
`long` type is missing in python 3, so np.long is still useful

README.rst

NumPy benchmarks

Benchmarking NumPy with Airspeed Velocity.

Usage

Airspeed Velocity manages building and Python virtualenvs by itself, unless told otherwise. Some of the benchmarking features in runtests.py also tell ASV to use the NumPy compiled by runtests.py. To run the benchmarks, you do not need to install a development version of NumPy to your current Python environment.

Run a benchmark against currently checked out NumPy version (don't record the result):

python runtests.py --bench bench_core

Compare change in benchmark results to another version:

python runtests.py --bench-compare v1.6.2 bench_core

Run ASV commands (record results and generate HTML):

cd benchmarks
asv run --skip-existing-commits --steps 10 ALL
asv publish
asv preview

More on how to use asv can be found in ASV documentation Command-line help is available as usual via asv --help and asv run --help.

Writing benchmarks

See ASV documentation for basics on how to write benchmarks.

Some things to consider:

  • The benchmark suite should be importable with any NumPy version.
  • The benchmark parameters etc. should not depend on which NumPy version is installed.
  • Try to keep the runtime of the benchmark reasonable.
  • Prefer ASV's time_ methods for benchmarking times rather than cooking up time measurements via time.clock, even if it requires some juggling when writing the benchmark.
  • Preparing arrays etc. should generally be put in the setup method rather than the time_ methods, to avoid counting preparation time together with the time of the benchmarked operation.