a new version of
ghpythonlib, the library performing NodeInCode, is in the latest version of Rhino 6 WIP.
We decided to rewrite the library to address a few requests and performance problems that were discovered over two years of intense usage by this community.
In the new version, on the feature side,
ghpythonlibhas now support for
Grasshopper DataTrees. It is now possible to feed a tree, and get the computed resulting tree as a result, thereby preserving data origins, and fully being able to recreate a Grasshopper definition in code. The new
ghpythonlib.tree.function()version of each function does no longer flatten results.
On the performance side,
- we corrected the behavior for known painful cases from the Grasshopper forum. You can see a series of test on the definitions below here.
- then, we tweaked the
ghcomponentlib.parallellibrary to use a new algorithm. While it will not make non-parallelizable computations run faster, this new code showed to improve performance in a series of cases.
Some real-world examples
We tested the new library thoughrouly with existing problem cases, and also with normal cases. The first impressions are encouraging:
- V5 vs V6: 16.9” vs 2.1” (⅛ the original time)
- Every new repetition was making the component slower. The problem is fixed now, and it’s also a lot faster the first time.
- V5 vs V6: 4.1” vs 0.376” (1/11)
- Here the “parallel” (multi-threaded) version of the script was tested. With this setup (just 3 boxes) I could not have the parallel version run faster than the iterative one; however, as the number of breps increases, the parallel version takes a smaller hit.
- V5 vs V6: 4.2” vs 0.429” (1/10)
- Here the code of the user runs unchanged, except for a typo he had in his definition.
- V5 vs V6: 66” vs 3.1” (1/21)
- It actually got even slower when the solution was recomputed.
- V5 vs V6: 0.5” vs 0.2” (1/2)
- Legendary sample by Steve: it runs unchanged, and it is quite faster too. This is mostly, but not only, due to new intersections code in Rhino