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?
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.
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.
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.