Brightway benchmarks
How long Brightway's calculations take in each released version, and whether they still give the right score. Every case runs on a synthetic database with the structure of ecoinvent, so no licensed data is involved.
Start with bw2calc's time for one score on the ecoinvent-sized database, per solver, across every release since 2.0. What the histories show so far is in the README.
Histories
- bw2calc
One score, a second functional unit, many functional units at once, and Monte Carlo draws, with each direct solver (SuperLU, PyPardiso, UMFPACK) and the iterative ones.
- bw2calc-conda
- bw2data
Writing a database, up to the size of ecoinvent.
- bw_graph_tools
Supply-chain graph traversal, small and large.
- bw_processing
Building datapackages from many resource groups.
- bw_timex
The time-explicit LCI as the timeline grows.
- matrix_utils
Building matrices from many resource groups.
Works together today
Each night the compat workflow installs the newest Brightway releases from PyPI
on each Python and runs every case once on a small database (latest), and again with
Brightway's dependencies at their lowest allowed versions (floors) or with
pre-releases (pre). The table shows how each job ended in the
run of 2026-10-28, and the last set that passed. Its
requirements.txt works as a constraints file, as in
uv pip install brightway25 -c requirements.txt; pylock.toml pins
the same set with each wheel's hash for that operating system. Both include pytest, which the
run needs. A set is kept for 90 days.
| Python | OS | Column | Latest run | Last green | brightway25 | bw2calc | bw2data | bw2io | numpy | Files |
|---|---|---|---|---|---|---|---|---|---|---|
| 3.12 | macos-latest | latest | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
| 3.12 | ubuntu-latest | latest | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
| 3.12 | windows-latest | latest | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
| 3.13 | ubuntu-latest | latest | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
| 3.14 | ubuntu-latest | latest | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
| 3.12 | ubuntu-latest | floors | failure | none kept | ||||||
| 3.14 | ubuntu-latest | pre | green | 2026-10-28 | 1.1.1 | 3.1.0 | 4.8 | 0.9.17 | 2.5.4 | requirements.txt · pylock.toml |
Reading the graphs
- Each point is one release. Lower is faster.
- Each line is one environment. For bw2calc the environment name says the solver:
pypardiso,scikit-umfpack, or neither for SciPy's SuperLU. A name withBWBENCH_SOLVERis an experimental solver patched into bw2calc:klu(KLU, through pyklu) orumfpack-T(UMFPACK factorizing Aᵀ). - Only the package changes along a line. Its dependencies stay fixed, so a step is the package's own change.
- Every timing ran one thread, pinned to one set of CPU cores. Compare points within a line, not times between machines.