Please see attached for a simplified definition that illustrates the issue:
I am referencing from one layer and baking to a different layer so I don’t think it is a layer conflict? Unless they are both trying to pull data from the Layer Table at the same time?
I have attached the simple GH definition and you can toggle between Rhino 8 & Elefront baking method to illustrate the difference; both solutions seem to result in freezing or severe performance degredation.
I was using legacy Elefront Reference By Layer & Bake Objects, both running in real-time/automatic update mode without any issues previously even in a very large and complex GH definition.
The workflow I used to use and what I expect the result to be is that I can reference geometry from the Rhino doc, perform GH operations based off of those geometry (treating the geometry as a sort of control guide reference), and then bake the resulting GH operations to the Rhino doc.
So as an example this script simply takes the boundaries of “floors” and tags them as such, when you move a sub curve or the overall floor curve, it should update those tag positions in real-time and then be done and not firing anymore logic unless a change is again detected in the reference geometry.
Downstream there would be additional logic based off of these input curves such as Floor slabs being created and baked, exterior walls being created and baked, etc. So multiple end results/bake results streaming from one single reference node.
In transparency I have also posted a parallel topic here focused on the Elefront side of things:
baking_infinite_loop_01a.gh (17.1 KB)
baking_infinite_loop_01a.3dm (199.1 KB)
Thank you for your help!