Newer IronPythons iterate more slowly?

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.

I moved this from Wasp Python components performance drop in Rhino 7 - #7 by ar0551 because it’s another topic, but might also be interesting to investigate.

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.

1 Like

Seems fairly comparable between 7 and 5 in the Rhino python editor outside grasshopper

1 Like

I would have also speculated that the blamed lies with IronPython but Graham’s post show that there’s more to it.
logged: RH-63487

1 Like

Great idea @Dancergraham. I am actually seeing the same pattern emerging as in GHPython (i.e. Rhino 5 computes about twice as fast as Rhino 7):

I would hope it isn’t due to the updated IronPython, which would be difficult to resolve :thinking:

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.

1 Like