Python scripts with ghpython components slow down grasshopper

Replies to This Discussion

Permalink Reply by Giulio Piacentino on December 7, 2015 at 7:07am

Hi Matti

thanks for starting this conversation.

Regarding question 1:

In general terms, GhPython does not store anything in central memory except the code that needs to run. It is certainly true that a script can write things to memory itself, though, or also to disk. In general, restarting Rhino will unload IronPython, and therefore clearing every Python module RhinoPython+GhPython have loaded.

For question 2:

Whether the geometry is originally part of the document or it is coming from Ghrasshopper itself should not make too much of a difference. GhPython currently duplicates every geometry type before running the script. Therefore, merely computationally, you are always working with a copy. If you are asking regarding keeping the definition responsive, probably a toggle like "ON/OFF" will help.

Please let me know if I can help with other more particular questions.

Thanks,

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

Permalink Reply by Anders Holden Deleuran on December 7, 2015 at 8:24am

In addition to Giulio's suggestions: Depending on what you are doing, these tips (1,2,3 in particular) might help speed up things without much change to your code. To find bottlenecks in the code itself you'll need to profile it. You can use the time module for a simple approach to this (see attached script for class that does this). Python also has more sophisticated profilers. 

Edit: If the problems lends itself to it, you can also consider multi-threading it.

Attachments:

• 151207_SimpleProfiler.py, 1 KB

Permalink Reply by Giulio Piacentino on December 7, 2015 at 9:02am

Thanks Anders. Regarding these tips, I would just add two remarks:

1. is fixed in Rhino WIP. The implied loop now costs even less than for other scripting component (on average).

Watch out for 3., if you edit items without copying/duplicating them first -- there will be disasters.

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

Permalink Reply by Matti Pirinen on December 8, 2015 at 11:19pm

Thank you both for your very helpful advices!

I timed one of my scipts and ran it 10 times and here is the result in ms:

 

3004
5946
11100
19627
32618
51169
75590
106387
146662
196901

 

As you can see the change in runtime is pretty drastic. I need to start timing different functions in my script to see what is actually going on. It has most likely something to do with my script not the grasshopper. I'll give you an update once I have enought time to investigate this further!

 

-Matti

 

 

Permalink Reply by Anders Holden Deleuran on December 9, 2015 at 1:36am

It's hard to troubleshoot without the actual code. Could be a memory leak (that's unlikely though in my experience with GHPython) or perhaps you're accidentally making a list larger each time you call the script (the profile times looks like a fairly exponential curve). Just to check: Are you running the latest Rhino 5 service release, Grasshopper, GHPython and .NET?

Permalink Reply by Giulio Piacentino on December 9, 2015 at 11:09am

Yes, when you get some time, could you tell which libraries you are using?
How is the code structured?

This would help us at least have an idea in which area to possibly expect the problem.

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

Permalink Reply by Matti Pirinen on December 9, 2015 at 2:36pm

Hi. Sorry that I havent posted the script yet. It is a little bit hard to follow and the commentary is written in Finnish (and i'm not very proud about the code either). So i'll give you a bit of insight on what i'm trying to accomplish:

So we are working on creating a code which whould create a Zollhau lamellen (picture below) type of structure on any freeform geometry. + would do the structural analysis + optimization for the geometry. The geometry consists from beams which span two edge segments of a mesh .

I'm using a mesh geometry edges to create the beams from. However when mesh edges are retrieved from the mesh they are not in the order i need them to be (picture below). So i'm trying to create a script which would reorder the edges in such a way that continuous beam lines would be found. Right now the code is extremely heavy since for every pair of edges the code searches through all the edges in the list.

 

Any help on creating this script is also greatly appreciated :). 

 

 

Attachments:

• mesh edge finder.gh, 11 KB

Permalink Reply by Markku on December 10, 2015 at 11:55am

Terve Matti

I tried to understand yor script but didn't got it due to ghpython error caused by ghpythonlib. Maybe I have to update my system to get rid of that error but if its enough to get those red and blue curve direction lines separated and joined, it can be done with gh basic components as in attatched picture and gh file.

Markku

Attachments:

• CanvasSnap.png, 142 KB
• meshedgefinder_M.gh, 14 KB

Permalink Reply by Matti Pirinen on December 10, 2015 at 3:07pm

Hi (Moro) Markku and thanks for joining the conversation.

 

Yes it would be great if I could manage with a simple derivate check. However I'm planning of dealing with meshes that change direction. However I think the derivates might be a key to simplify my code. Right now i'm dealing only with curve end points. I need to look further into that area!

There might be something wrong with my code, which gives you an error. It is a work in progress (unfortunately it seems I only have time to progress it during the nights).

 

Here are couple of pictures of the project we are working on right now, which gives you an idea what kind of meshes I would like to use the code on:

Permalink Reply by Andrew Heumann on December 9, 2015 at 11:31am

Matti - are you by any chance using the ghpythonlib / gh components in tandem with multi-threading? This has been a source of trouble in the past, with similar (progressively slower execution) behavior. 

See my posts on the subject here:

http://www.grasshopper3d.com/forum/topics/multithreading-with-python

http://discourse.mcneel.com/t/ghpython-parallel-component-slower-th...

http://discourse.mcneel.com/t/new-ghpython-issues-crashing-multithr...

Permalink Reply by Matti Pirinen on December 9, 2015 at 2:42pm

Thanks for the tip!

I havent used the multi-theading yet. However i'm planning to implement it soon since the code seems to get quite heavy