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.
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.
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!
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âŚ
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.
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.