It might also be worth noting that GHPython performance appears to have dropped in general, at least in cases with many iterations/large computations. It’s a pattern I starting noticing when Rhino 6 launched, where my Rhino 5 definitions developed using GHPython “felt” slower on Rhino 6.
Here’s a super simple, but consistent, example. Rhino 5 vs Rhino 7:
I think we did discuss this issue back when Rhino 6 launched. And assumed it was due to updating IronPython. I never did analyse this further (e.g. run different versions of IronPython outside Rhino and benchmark) to verify this conjecture though.
Maybe @Alain can tell more regarding this. He and @stevebaer have been keeping IronPython up-to-date over the years.
My first guess would be that the IronPython team figured out some problems in the first implementation, and later added some checks that take a little time. However, maybe these checks are vital for correct behavior. But this is only speculation.
I missed this topic, but for sure it’s internal to IronPython,… There might be, in addition, changes to the Garbage Collector by Microsoft. It might be that it’s more aggressive and notices a major memory increase (range() creates a huge list) and therefore tries to reclaim memory.
