The OpenGJK library is continuously tested for accuracy and performance. This page shows the result of benchmarks that test the runtime performance of the library. This page is automatically updated each time a new version of the library is released. It serves as a dashboard that quickly summarizes where recent development has led to - in terms of speedup.
The latest benchmarks ran on a shared virtual machine (GitLab CI runner).
Loading data ...
Number of v-CPU:Loading data ...
CPU(s) frequency in MHz:Loading data ...
The OpenGJK is called for three simple scenarios:
For each scenario the mean, median, standard deviation and coefficient of variation (cv) is reported for the runtime (CPU time). The results are reported below in logarithmic scale.
The heatmap below shows how performance has evolved across all tagged releases of OpenGJK. Green indicates faster execution times, red indicates slower times.
| Version | Pair of Points | 100 Vertices | 1000 Vertices | Released |
|---|---|---|---|---|
| v3.0.01b84855 | 1.52 | 5.85 | 108.5 | Jul 2022 |
| v3.0.17a018a3 | 1.48 | 5.68 | 104.2 | Nov 2022 |
| v3.0.2866c01e | 1.42 | 5.45 | 99.8 | Nov 2022 |
| v3.0.39d9e8e4 | 1.38 | 5.32 | 97.5 | Nov 2022 |
| v4.0.0ad2d602 | 1.21 | 4.68 | 85.8 | Apr 2023 |
| v4.0.1855c5c0 | 1.19 | 4.62 | 84.2 | Dec 2023 |
| v4.0.2ba1d826 | 1.18 | 4.55 | 83.1 | Nov 2024 |
| v4.0.3bc0b389 | 1.15 | 4.48 | 81.5 | Feb 2025 |
| v4.0.45eca7fa | 1.12 | 4.35 | 79.2 | Dec 2025 |
Faster Slower · CPU time in μs, lower is better
Pair of Points 1.52 → 1.12 μs −26.3%
100 Vertex Polytopes 5.85 → 4.35 μs −25.6%
1000 Vertex Polytopes 108.5 → 79.2 μs −27.0%
v3.0.0 (Jul 2022) compared to v4.0.4 (Dec 2025)
An alternative view showing the performance trend as a line chart.
| Version | Pair Points (μs) | 100 Vertices (μs) | 1000 Vertices (μs) | Date |
|---|---|---|---|---|
| v3.0.0 | 1.52 | 5.85 | 108.50 | 2022-07-09 |
| v3.0.1 | 1.48 | 5.68 | 104.20 | 2022-11-01 |
| v3.0.2 | 1.42 | 5.45 | 99.80 | 2022-11-23 |
| v3.0.3 | 1.38 | 5.32 | 97.50 | 2022-11-28 |
| v4.0.0 | 1.21 | 4.68 | 85.80 | 2023-04-22 |
| v4.0.1 | 1.19 | 4.62 | 84.20 | 2023-12-28 |
| v4.0.2 | 1.18 | 4.55 | 83.10 | 2024-11-26 |
| v4.0.3 | 1.15 | 4.48 | 81.50 | 2025-02-16 |
| v4.0.4 | 1.12 | 4.35 | 79.20 | 2025-12-29 |
Beyond micro-benchmarks, we also profile the library in a realistic physics simulation scenario.
The superb mini-application runs hundreds of collision shapes with multi-threaded physics,
giving insights into real-world performance characteristics.
Profile of the OpenGJK-powered physics simulation (superb app)
running 800 collision shapes
on macos.
Thread Balance
excellent 11.0% – 11.1% per thread Workload is nearly perfectly distributed across all worker threads.
CPU Time Hotspots
| Function | CPU % | Time (ms) |
|---|---|---|
compute_minimum_distance |
9520 | |
PhysicsWorld::workerThreadFunc |
6360 | |
CollisionShapeArray::fillGJKBuffer |
3480 | |
W1D |
445 | |
S2D |
355 | |
__sincosf_stret |
385 |
Analysis Summary
The workload is nearly perfectly distributed across all 8 worker threads. Each thread consumes 11.0-11.1% of total CPU time with uniform self-weight distribution. The main hotspot is compute_minimum_distance at 36% total time. Optimization suggestions include caching GJK buffer data (potential 10-12% speedup) and enhanced SIMD vectorization (potential 15-20% speedup).