algorithmic modeling for Rhino
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)?
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?)
for Robert McNeel & Associates
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.
Good news! The library is now rewritten in Rhino WIP. http://discourse.mcneel.com/t/new-version-of-ghpythonlib-components...
You are not alone. This has been happening to me too... mentioned here: http://discourse.mcneel.com/t/new-ghpython-issues-crashing-multithr...
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.
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.
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.
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.
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).
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.
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:
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.
- 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.
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.
I guess it makes sense. Thanks a lot.
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.
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.