ghPython slows down on subsequent runs

Hello, I am very annoyed by a problem I have when running a certain script multiple times in a row. As you can see in the attached image, the script slows down dramatically on subsequent runs.

The idea behind it was to optimize the SurfaceSplit command when you input multiple surfaces to only call the component when the surfaces actually intersect. It uses a SurfaceClosestPoint to check if they intersect and if so performs the split.

I can't understand why each subsequent component runs slower than the former. I get the same behaviour if I turn the same component on and off in succession.

Could it be because of a memory problem which the script should handle? Or maybe the rhino (sr7) or grasshopper version (0.9.0068)?

I've also attached the script. Thank you for any ideas you could share.

Attachments:

script.py, 1 KB

Replies to This Discussion

Permalink Reply by Giulio Piacentino on January 28, 2014 at 3:43pm

Hi Sabin

would you be able to attach the whole definition? It will take a long time to recreate it otherwise... (or a part that shows the problem?)

Thanks,

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Sabin Serban on January 31, 2014 at 5:53am

Hi Giulio,

sorry for the late reply. Here's what you asked for. I hope this illustrates the problem correctly. I am getting times from about 10sec on the first component on the first run to more than 2 minutes if I run all the components a second time.

Attachments:

bug test.3dm, 1 MB
bug test.gh, 45 KB

Permalink Reply by Giulio Piacentino on July 14, 2016 at 10:23am

Good news! The library is now rewritten in Rhino WIP. http://discourse.mcneel.com/t/new-version-of-ghpythonlib-components...

Permalink Reply by Andrew Heumann on January 28, 2014 at 4:16pm

You are not alone. This has been happening to me too... mentioned here: http://discourse.mcneel.com/t/new-ghpython-issues-crashing-multithr...

quote:

I am concerned that some sort of memory leak is occurring. I have now noticed several times that every time a complex, multithreaded python script runs, its execution time is significantly slower than the previous time, even with identical data. In the attached definition, when I enable the python component the first time, it calculates in 8.4 seconds. If I repeatedly reconnect one of the inputs, it goes up to 13.8, then 24.8, then upwards of 2 minutes. See the attached video for one example of such a run cycle. I have edited the video for speed but you can clearly see the difference.

Permalink Reply by Andrew Heumann on January 28, 2014 at 4:17pm

It's my opinion that it is a problem with ghpythonlib.components... if I avoid this and only use sdk functions the problem goes away.

Permalink Reply by Sabin Serban on January 31, 2014 at 6:07am

Hi Andrew,

when you say sdk functions you mean the rhinoscript functions, right? The problem is that I don't really know how to make a curve put a hole through my surface with the rhinoscript functions.

Permalink Reply by djordje on January 31, 2014 at 8:54pm

There is no rhinoscript function that splits surface with a curve. You can only split it with another surface or plane. Therefor a work around would be to extrude your curves, and then split those extrusions with your planar surface.

But what Andrew meant was RhinoCommon methods, which is the underlying power and SDK bellow both rhinoscript functions and grasshopper components.

Currently there is no RhinoCommon Surface method that splits surface with a curve (I am very curious how does the grasshopper component "SrfSplit" does that).

Giulio made an example of how this could be achieved with BrepFace by using its Split method.

I attached the file that works according to his code.

Still, if you solve the gradual slow downs on subsequent runs, you have another problem: you are passing a total number of 1200 curves to each of your planar surfaces to cut them. And you are doing that times 4.

Even multithreading would not be able to lower down the calculation time bellow tens of seconds.
So you definitively need to somehow separate (inclusion maybe?) those cutting rectangles into only those that correspond to certain surfaces.

Attachments:

bugtest2.gh, 56 KB

Permalink Reply by Sabin Serban on February 1, 2014 at 4:00am

Wow, thanks for the example. I implemented it and now it draws all the holes on all the patches in just 12 seconds. I was already handling the problem with all the curves you talked about with the surfaceClosestPoint check in my example. But now, by using the rhino methods it's much faster.

If you want to check it out, here's my implementation.

Now, on a side note:

Rhino.Geometry.BrepFace.Split needs as arguemnts a surface and a IEnumerable [curves] I don't understand why it would not take a polycurve as an argument instead of the IEnumerable
face.DuplicateFace(False) what does this do? If I just use face I get only some small rectangles with no holes. If I use this thing I get the whole surface with all the holes

Anyway, thanks a lot djordje and Giulio for the code.

Attachments:

bugtest3.gh, 34 KB

Permalink Reply by djordje on February 1, 2014 at 5:53am

- IEnumerable means (at least in Python), that you need to supply a list of curves and then the method will do a loop through that list on its own. You probably supplied just on curve, so that' why an error emerged.

- "face.DuplicateFace()"

Not sure really.

If you append to list "a" just faces, information on trim curves, gets lost so that is why you get all untrimmed surfaces.

Maybe "DuplicateFace" duplicates a BrepFace from a collection of BrepFaces within a Brep, and then creates a single Brep from each of those BrepFaces. In that way the resulting Breps have trim curves too, so you could get a trimmed surfaces as well.

Again, it might be better to ask David or Giulio about this.

Permalink Reply by Sabin Serban on February 1, 2014 at 9:07am

I guess it makes sense. Thanks a lot.

Permalink Reply by trevor.patt on May 2, 2014 at 6:57am

I have a similar problem happening when I edit the code inside a ghPython module multiple times.

Every solution takes longer than the previous, even when changes are made to speed up the processing. For example, I had a bit of code which ran in ~45s according to the profiler. After a series of edits, it ballooned to ~60 minutes(!), but when I closed Rhino and reopened Grasshopper, it now ran in ~40s, a slight improvement.

This makes it pretty much impossible to evaluate improvements without completely closing the program and reloading everything in between every edit and also makes it difficult to follow the good practice of frequently making/checking small edits to code.

Are there any recommendations for avoiding this phenomenon? It seems the standard python tips for speed/performance optimization don't always translate to ghPython.

Permalink Reply by djordje on May 2, 2014 at 7:07am

Hi Trevor,
Have you been using RhinoCommon methods inside of ghPython?

Check this topic on present "discoveries" with ghpython speed issues. I think Steve and Giulio are currently working on solving some of those.