Benchmarks
The following benchmarks were performed on a 4-Core, 2.5GhZ CPU, with 16GB of DDR3 RAM. Impala's strategy of reducing contention results in most components enjoying a linear speedup relative to the number of cores. Certain input patterns such as grafted trees are limited by allocation incurred by Grasshopper interop rather than the actual computation, and performance is much more variable in these cases.
- Baseline (in blue) shows the performance of a native, Grasshopper implementation (using Rhino 5, GH pre 1.0)
- Impala (in red) shows the performance of a Impala plugin implementation
Components are tested on exactly the same inputs.
On a flat input pattern and randomly generated trees, we observe a huge performance increase:
| Flat | Random |
|---|---|
 |
 |
On a grafted input (tree with branches of length 1) we observe a significant performance hit, and Impala is comparable to the native implementation. Impala delivers more significant improvements given an average branch-length of 5 or higher.
| Grafted (1) | Grafted (5) |
|---|---|
 |
 |
This is largely due to allocation overhead. Impala does not access GH_Structure<T>'s internals when interoperating with other Grasshopper components. When Impala creates more branches, the unused references to these arrays produce extraneous allocations. Still investigating ideas on how to improve this.
| Point Closest Point | Closest Curve Closest Point |
|---|---|
 |
 |
These are parallel implementations of their GH counterparts. These usually achieve close to linear speedup on most input sizes, and can outperform existing multithreading components.
| Curve-Curve SingleThreaded | Curve-Curve Multithreaded |
|---|---|
 |
 |
Extension components provide additional composition, chunking out large parallel operations and reducing the time spent copying or casting values around. As a result they usually achieve super-linear speedups compared to their Grasshopper equivalents.