Update data only when needed .... ?

Replies to This Discussion

Permalink Reply by David Rutten on May 16, 2017 at 6:52am

This is a possible alternative approach to running solutions, however it doesn't work well within the current GH SDK. The current approach is to just erase all data as soon as something expires, and this wave of erasures propagates throughout the document. All the current data is lost, so when new data comes along there's nothing there to compare it against. In order for your suggestion to work, old data needs to be kept long enough so it can be compared to new data. If, after the comparison, it turns out the new data is identical to the old data, then the old data can be re-used downstream.

Just beyond the fact that the current system is not set up for such an approach, there are several problems with it. Chief among them are:

1. In addition to calculating a new solution, we now also have to perform a lot of comparisons. I don't know how common it is for a new solution to be able to re-use large chunks of data from a previous solution, but I do know you have to compare all the values before you can be certain that the before and after states are identical.
2. Comparisons can be complicated or even impossible for certain data types. It is also impossible sometimes to define a universally agreed on equality. If you have two breps that have the exact same shape, but the order in which faces are stored is different, is it still the same brep? How about userdata on those breps? Is that allowed to differ? If not then you're in trouble, because plug-in specific user data is not accessible from a different assembly so you'd have no way to test for equality.

The good news is that GH2 will retain solution data longer than GH1. This is necessary because GH2 solutions run on background threads and the old data needs to still be previewable in Rhino viewports while the new solution computes. This at least provides a mechanism by which data before and after a solution could be compared, and even a way for old data to be re-instated without new data having to be computed.

But even in this new scheme I'm hesitant to try and be 'clever' about this. Because if you get it wrong you introduce a bunch of really hard to detect and work-around bugs, and that's not even to mention the increased complexity of the solution logic in general, which is already incredibly convoluted and difficult to debug.

Permalink Reply by Riccardo Majewski on May 17, 2017 at 4:09pm

Thanks for the exhaustive answer, David... as expected.

Doing this check all the time it would be a heavy load, ok...

Maybe something like a MD5 checksum?

Still I don't quite get why all the data needs to be expired and recalculated every time... but I am certainly far away from even imagining the whole complexity of the situation here (:

... maybe what i need could be solved just with a smart use of data dam component.