Because there would be no point to it. Changes to a document need to happen in a pretty unambiguous order because objects need to be moved to a chronologically linear undo buffer and some operations require the document to be in a valid state. If multiple threads are all making changes to the same document at the same time there will be racing conditions.
I’m not terribly shocked it takes a second to update 500 objects in the Rhino document though. The document wasn’t designed to handle a huge throughput of changes because Rhino was never meant as an animation package. The assumption until very recently has always been that the document is modified by commands that people run by pressing buttons on a keyboard or a mouse. It’s only when you start to do this sort of stuff from sliders that the delay becomes really noticeable.
Don’t get me wrong, I’d love for it to be faster. But the times you’re getting tell me there’s nothing wrong with your code, it’s just the way Rhino is.
I haven’t tried this, but would it be a possibility to let multiple instances of Rhino do the baking (with the baker acting as a round robin), and then collect (import) the resulting object? Too complex to set up?
perhaps. Anyway, depending on what kind of baking to be done I imagine that one could split the job up and let for example two Rhino instances do half of the job each, where one bakes odd number of instances and the other bakes even numbers (or divide the job even more if need be).
Would that work? Does GrassHopper have anything inbuilt that would simplify this kind of thing? Perhaps the Elefront plug-in had something. I recall they performed massive computations in parallel with multiple instances of Rhino. In the following video (about the Morpheus Hotel project) they talk about their experiences from such massive computations.
Fig.1. One of the most interesting videos I’ve seen on what you can do with Rhino. Worth every minute: