GHPython Slightly Slower in V6

Hi @piac and @stevebaer

I was just testing out a few definitions for the first time in the V6 and felt like they performed slightly more sluggish than what I remembered in V5. Was just wondering if you guys have run some performance tests between the two versions yourselves? There’s a related thread here BTW.

Did a quick rudimentary one, just to verify whether I was imagining things, and in this case (a simple loop with increasingly more iterations), there does appear to be a slight performance hit in V6:

I wonder if this might because of upgrading IronPython, or something else entirely. Either way, it just caught me a bit off guard and seemed like cause for concern (assuming this it accurate). Would hate for a newer GHPython to run worse than the old one :confused:

Cheerio,

Anders

The test file:
171209_GHPython_V5toV6_BasicPerformanceTest.gh (8.5 KB)

Hi @AndersDeleuran

you can see it in the code: the calculation is based entirely on IronPython. I suppose that there was a subtle bug in the + operator, so they had to add a small if : or something…

That aside, a change around 5%/10% is hard to feel, and might actually be the opposite once we switch to 2.7.7.0 (right now it’s 2.7.5.0) for V6 SR0 or SR1. There isn’t much we can do, if we want to support the newer language version.

On a happier note, I’ve seen several computation where V6 GhPython is orders of magnitude faster than V5. Like, 100ms vs 5ms. So, for now, this does not seem so worrying.

We need to keep an eye on this, though, and see how it evolves, so feel free to keep us posted :slight_smile:

1 Like

Wohoo, now that’s more like it! That all makes sense, just wanted to check in. Looking forward to taking the full V6 plunge, after which I’m sure I’ll be back with plenty more feedback :wink:

Cheers again…

1 Like

The case was discussed here: New version of ghpythonlib.components

Ah yes, right, I remember the ghpythonlib improvements. The behaviour I’m seeing though, seems indeed perhaps to be related to IronPython. Here’s another basic test (using RhinoCommon to make many lines), again V6 is slightly slower:

File: 1712058_V5toV6_GHPython_RhinoCommon_Polyline_00.gh (8.8 KB)

Look at what happens if the “GH_Component SDK version” of the same is executed (V6 only)…


1712058_V5toV6_GHPython_RhinoCommon_Polyline_01.gh (12.8 KB)

I think this might have, at least in part, to do with the likelihood of having a .Net garbage collection happening right in the middle of our calculation. V5 and V6 “normal” components invoke the IronPython engine with the same method, while V6 “GH_Component SDK mode” caches the compiled code, so that might have to do with explaining the GC timings, as well.

All in all, this example is quite simple. It would be good to compare real cases, and see if real bottlenecks appear. (5% difference is hardly worse automatically). Here this goes about 30% faster.

1 Like

Yeah garbage collection does seem like it might explain some of this. Haven’t tried out the SDK mode yet, sounds very interesting.

I’ll be sure to test more in-depth once I get around to moving over production definitions to V6.

1 Like