binary-trees benchmark N=14
Each chart bar shows how many times slower, one ↓ binary-trees program was, compared to the fastest program.
These are not the only programs that could be written. These are not the only compilers and interpreters. These are not the only programming languages.
Column × shows how many times more each program used compared to the benchmark program that used least.
| sort | sort | sort | ||||
| × | Program Source Code | CPU secs | Elapsed secs | Memory KB | Code B | ≈ CPU Load |
|---|---|---|---|---|---|---|
| 1.0 | Pyston #7 | 0.75 | 0.16 | ? | 741 | 61% 81% 62% 50% 65% 59% 62% 61% |
| 1.2 | Python development version #7 | 0.88 | 0.18 | ? | 741 | 65% 61% 63% 53% 55% 85% 59% 63% |
| 1.4 | Python development version | 1.05 | 0.21 | 2,296 | 706 | 62% 57% 60% 62% 62% 55% 86% 65% |
| 1.4 | Python 3 #7 | 1.03 | 0.22 | 3,584 | 741 | 81% 62% 55% 57% 64% 57% 62% 57% |
| 1.4 | Nuitka #7 | 1.06 | 0.22 | 2,304 | 741 | 70% 62% 59% 59% 59% 82% 59% 55% |
| 1.4 | Pyston #6 | 1.09 | 0.22 | 45,372 | 743 | 64% 57% 59% 81% 60% 59% 71% 65% |
| 1.5 | Python development version #6 | 1.18 | 0.23 | 111,996 | 743 | 61% 55% 95% 61% 60% 65% 57% 61% |
| 1.7 | Python 3 | 1.19 | 0.26 | 100,836 | 706 | 61% 58% 58% 62% 58% 85% 50% 54% |
| 1.7 | Python 3 #6 | 1.36 | 0.27 | 105,876 | 743 | 88% 64% 57% 62% 59% 65% 59% 63% |
| 1.8 | Nuitka #6 | 1.39 | 0.27 | 96,932 | 743 | 59% 61% 65% 81% 62% 63% 63% 63% |
| 1.8 | Nuitka | 1.24 | 0.29 | 94,936 | 706 | 52% 50% 89% 52% 52% 57% 53% 48% |
| 2.0 | Pyston | 1.05 | 0.31 | 82,980 | 743 | 55% 52% 66% 43% 43% 41% 38% 37% |
| 3.0 | Python 2 | 2.02 | 0.47 | 16,340 | 743 | 54% 57% 56% 54% 64% 57% 63% 54% |
| 5.8 | PyPy 3 #7 | 2.28 | 0.90 | 128,080 | 741 | 63% 24% 24% 26% 27% 27% 36% 37% |
| 6.7 | PyPy 2 | 2.27 | 1.04 | 91,028 | 743 | 32% 67% 25% 28% 24% 28% 22% 24% |
| 6.8 | PyPy 3 #6 | 3.07 | 1.06 | 88,640 | 743 | 34% 37% 65% 34% 34% 29% 31% 32% |
| 8.1 | PyPy 3 | 2.94 | 1.26 | 88,732 | 706 | 69% 29% 24% 23% 28% 31% 28% 26% |
| 410 | Numba | 5 min | 63.59 | 154,632 | 734 | 73% 70% 76% 94% 76% 74% 69% 75% |
| missing benchmark programs | ||||||
| Jython | No program | |||||
| IronPython | No program | |||||
| Cython | No program | |||||
| Shedskin | No program | |||||
| MicroPython | No program | |||||
| Grumpy | No program | |||||
| Graal | No program | |||||
| RustPython | No program | |||||
binary-trees benchmark : Allocate and deallocate many many binary trees
diff program output N = 10 with this 1KB output file to check your program is correct before contributing.
We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
Each program should
- define a tree node class and methods, a tree node record and procedures, or an algebraic data type and functions, or…
- allocate a binary tree to 'stretch' memory, check it exists, and deallocate it
- allocate a long-lived binary tree which will live-on while other trees are allocated and deallocated
- allocate, walk, and deallocate many bottom-up binary trees
- allocate a tree
- walk the tree nodes, checksum the node items (and maybe deallocate the node)
- deallocate the tree
- check that the long-lived binary tree still exists
Note: this is an adaptation of a benchmark for testing GC so we are interested in the whole tree being allocated before any nodes are GC'd - which probably excludes lazy evaluation.
Note: the left subtrees are heads of the right subtrees, keeping a depth counter in the accessors to avoid duplication is cheating!
Note: the tree should have tree-nodes all the way down, replacing the bottom nodes by some other value is not acceptable; and the bottom nodes should be at depth 0.
Note: these programs are being measured with the default initial heap size - the measurements may be very different with a larger initial heap size or GC tuning.
Please don't implement your own custom memory pool or free list.
The binary-trees benchmark is a simplistic adaptation of Hans Boehm's GCBench, which in turn was adapted from a benchmark by John Ellis and Pete Kovac.
Thanks to Christophe Troestler and Einar Karttunen for help with this benchmark.