Grasshopper "slow" Baking [SOLVED]

600.000 lines baked with python, from GH to Rhino, including 5-6 userText data, is getting 15 minutes. (well baking without python, the regular way, is as slow)
Point baking is performing considerably better. 120000 points-30 sec, approx.

@ GH developers: Is this acceptable performance?
Maybe an efficiency issue behind the scenes?
just guessing

That’s a difficult question to answer. Easier would be to ask whether this is expected performance. I don’t know the answer to that either, but it’s at least something I can investigate. It is expected that points would be quicker than lines, as they are simpler kinds of objects. I’ll have to run some profiled tests myself.

600k objects is quite a lot, but then 15 minutes is quite a lot as well.

@DavidRutten, exactly, acceptable as long as it is expected. This is the actual sense of my question.

i´am aware of the size of the project, and 15 minutes is not really as much in my current workflow (time for a coffee and cigarrette), but just wanted to know if this software, fine tunned, is capable of more.

I´am quite suspicious, because geometry displaying operations are being pretty fast (few seconds) when previewing from Grasshopper (i´am suposing grasshopper is using somehow rhino´s Display Pipeline), and I just cant figure out what operations are taking so long, when apparently, is a process of writing a bunch of data (750 mb when saved) into memory, presumably the operation consist of the creation of Rhino DocObjects with attributes et al. from pure Rhino.Geometry.Lines.

but i´am ignorant of what is really happening behind the scenes, and so my question.

The problem may well be that the Rhino document wasn’t designed for this. When they wrote it, it was unlikely that there’d be a huge throughput of objects. The only commands in Rhino that insert lots of objects are exploding pointclouds and ArrayXXXX, and those actually feel pretty sluggish in my experience.

The Rhino document was designed to be safe, and heavily bottlenecked, and fast once populated, but not necessarily fast to be populated.

But this needs some performance profiling to see if the bulk of the time is spend in Grasshopper, RhinoCommon, or Rhino core.

certainly populating rhino document with 600.000 lines using array tool is taking similar time to finish the process.

With grasshopper at play, the generation of a vast amount of geometry shouldn´t be treated as anecdotical by Rhino, in my opinion.

Can you run the SystemInformation command in Rhino and post the results here? (It’s in the help menu of Rhino).

I want to make sure there aren’t plug-ins that could potentially be getting in the way.

@stevebaer
Rhino 6 SR4 2018-5-4 (Rhino 6, 6.4.18124.12321, Git hash:master @ 396f4c3420cadef29ac36e4307c8f98f7753c933)
Licence type: Commercial, build 2018-05-04
License details: LAN Zoo Network Node

Windows 10.0 SR0.0 or greater (Physical RAM: 40Gb)
Machine name: ALECETA2017

Quadro K2200/PCIe/SSE2 (OpenGL ver:4.6.0 NVIDIA 391.58)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 4-30-2018
Driver Version: 23.21.13.9158
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 4 GB

C:\Program Files\Geometry Gym\Rhino3d\ggRhinoIFC.rhp “ggRhinoIFC”
C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
C:\Program Files\Geometry Gym\Rhino3d\BullAnt.rhp “bullant”
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Users\aleceta\Downloads\elefront0410\ElefrontProperties.rhp “ElefrontProperties”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI”
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 6\Plug-ins\import_ACAD.rhp “AutoCAD file import: import_ACAD”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles”
C:\Program Files\Rhino 6\Plug-ins\Grasshopper\GrasshopperPlugin.rhp “Grasshopper”
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”

Thanks, here’s something to try. Start Rhino and run the following python script

This takes a little over 5 seconds on my computer. If this takes a lone time, try disabling all plug-ins that do not ship with Rhino (ggRhinoIFC, bullant, ElefrontProperties", restart Rhino and try the python script again. This might help us figure out what is going on.

wow…!!

you were right. Here at home, the behaviour was the same. Super slow baking.
Now, I have disabled Bullant et voila! more or less 5 seconds baking (from python) 600.000 lines. So impressed!

thank you very much, @stevebaer

btw, no more extra plugins istalled in this computer. I will try it again at office tomorrow.

@jonm any ideas of what is happening? GGRhinoIFC was enabled so no problem with this plugin. I Only disabled Bullant, and baking process passed from 15 minutes to 5 seconds…


Rhino 6 SR5 2018-5-29 (Rhino 6, 6.5.18149.14421, Git hash:master @ 39e73a6a93c18c92e40c05cb323c990246a30569)
Licence type: Comercial, build 2018-05-29
License details: Cloud Zoo. In use by: Aitor Leceta (Grupo_Leceta)

Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)
Machine name: AMDWORKSTATION

GeForce GTX 760/PCIe/SSE2 (OpenGL ver:4.6.0 NVIDIA 391.35)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 8x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 3-23-2018
Driver Version: 23.21.13.9135
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 4 GB

C:\Program Files\Geometry Gym\Rhino3d\ggRhinoIFC.rhp “ggRhinoIFC”
C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
C:\Program Files\Rhino 6\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 6\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI”
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\Alerter.rhp “Alerter”
C:\Program Files\Rhino 6\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles”
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars”
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”

Thanks for posting, and sorry for the negative impact Bullant causes here.

Basically in Bullant (originally known as StructDrawRhino) there is some events that it subscribes to, primarily relating to the structural sketching as demonstrated here:

Bullant is notified every time an object is added to the document, and tests if it should respond.
I’ve been hoping to overhaul this for some time, and actually move it from Bullant to the ggRhinoIFC plugin. This includes rethinking the event watcher (with more user control on when it was active). Note this code is 10 years old (when Grasshopper was really only emerging).

I’ll add this report as extra motivation to get to work on this.

Cheers,

Jon

1 Like

I see…
so, I dont need bullant to have installed if ggRhinoIFC is already on the machine?
I use your software for IFC creation from Grasshopper, so maybe bullant is not crucial in my case?

I think is a great contribution what you made with ggRhinoIFC and ‘GG’ ecosystem in general.

Bullant isn’t absolutely required for ggRhinoIFC, although again legacy comes into play.
Many of my older grasshopper example scripts used the bullant catalog component. But a few years ago I added the equivalent into ggRhinoIFC plugin so if you do open old scripts, you can manually repair.

I will look at removing the event watcher for the next build, you can also disable loading temporarily until you need bullant again.

thanks jon, good to know.
I thought (dont ask me way) there was a dependency between ggRhinoIfc and Bullant.