Performance issue due to background buffering?

Hi David,

I just moved to GH 0.90075 and something happened since 0.90014: it seems that the components that are embedding geometry that I did for the robot library are taking a crazy amount of time to be loaded (like 5 minutes), while before it was 300ms. I suspect it is related to some buffering that you added in the new versions, but I don't know for sure. Would you have a clue on how to go back to an acceptable loading time for these components? Maybe I missed an update in the SDK?

By the way, the screeshot utility is not exporting the profiler results.

Have a nice day,

Replies to This Discussion

Permalink Reply by David Rutten on May 18, 2014 at 1:17pm

So this is geometry stored in the Persistent Data? I don't think that part of the code changed much, it certainly shouldn't have gotten slower.

Can you post a file that shows the problem?

David Rutten

david@mcneel.com

Permalink Reply by Thibault Schwartz on May 20, 2014 at 4:11pm

Hi David,

Thanks for your quick reply, I will send you a sample tomorrow.

Permalink Reply by Thibault Schwartz on May 22, 2014 at 8:49pm

Hi David,

It seems that this bug only occurs on Rhino 5 x64, I can load all the presets properly on x86.

I am still on SR6 so it may have been fixed already.

You can test with the gha that I uploaded here. Pick the "IRB6640" component in the Robotics/Robot Library menu: it's taking 59s to solve in x64, around 1s in x86.

No persistant data, only hard-coded meshes that are called when the component is loaded.

Permalink Reply by Thibault Schwartz on May 31, 2014 at 9:40am

Hi David,

I just updated Rhino to the last SR9 build, and I confirm that this bug only happens in the 64 bit version. The performance drop is of 20 to 25 times, from x86 to x64.

Have a nice weekend,

Permalink Reply by Luis García Lara on May 19, 2014 at 1:38pm

i have the same issue, feel like grasshopper use all the memory and then just don't execute the solutions...this happens without matter how long and complex of the definition...

Permalink Reply by David Rutten on May 19, 2014 at 1:46pm

Is this regarding the Robot tools too, or just native GH?

David Rutten

david@mcneel.com

Permalink Reply by Luis García Lara on May 19, 2014 at 1:48pm

In my case just native gh component...and starling meshes comp...

Permalink Reply by ng5 Alex on May 19, 2014 at 1:56pm

starling meshing components were a bit heavy since their release, but not completing the solution seems a bit strange (unless very complex geometry is involved).

Permalink Reply by David Rutten on May 19, 2014 at 2:01pm

Can I see a file that takes forever to solve?

David Rutten

david@mcneel.com

Permalink Reply by Luis García Lara on May 19, 2014 at 2:40pm

Here's the file.

Thanks!

(The last time I saved disabling the solution solver, copy all the components and saving in a new canvas, and the solver is working again)

Attachments:

20140519+.gh, 44 KB

Permalink Reply by David Rutten on May 19, 2014 at 3:27pm

Thanks, I'll test asap.

David Rutten

david@mcneel.com

Permalink Reply by Arend on May 30, 2014 at 6:17am

Perhaps related, perhaps not - but I've encountered that for some operations that create a lot of geometry (especially breps) - the meshing and displaying of the solution can take a lot longer than the solution itself. This is not an operation that I've been able to skip or abort before switching to wireframe or no render mode.

RSS