@mjkkirschner I've added a test.

@aparajit-pratap thanks! I will build on top of this test with a large element binding example of the scale which replicates the issue.

@saintentropy @aparajit-pratap @QilongTang I have done the following:

• re-enabled the existing callsite tests that were marked failure after getting them to pass
• added traceBinder unit tests
• added a perf test that asserts loading trace data for 1500 elements is accomplished in < 20 seconds. Currently this takes ~~2 seconds after this pr with my local set of assemblies.

PTAL

@aparajit-pratap on my vm - the loading of trace in this test takes 34 seconds before the change, after it takes 1.1 seconds - I ran them both a few times, this appears to be the average on my machine.

@mjkkirschner while these changes are great and will improve the deserialization of all kinds of custom classes that people have decided to save to their dynamo graph, isn't serializing the entire wrapped object for each bound element too much? I was just wondering if a special and more light-weight method could be implemented for those cases, one that stores only the unique id of the element as a string? Right now every public member of the wrapped object will get serialized, when all we need is the guid. All other parameters might have changed between the time the graph was saved last and the latest version of the Revit model it was used with and that would most likely invalidate the trace data.

If that's viable, it could hopefully improve both the robustness and the performance of element binding in general.

Hi @dimven Right now every public member of the wrapped object will get serialized, when all we need is the guid. this is not the case - in trace we only serialize the serializeableID class which is usually just an id - Directshapes serialize a bit more info. Unfortunately this uses SOAP formatter serialization which serializes a bunch of other info required for deserialization based on specific assembly version etc. The data is also base 64 encoded which actually makes it larger...

So your initial point is definitely valid, it's just maybe not as bad initially - or bad in other ways 😄 .

You can see what's in trace by base64 decoding it, and then base 64 decoding the individual elements again.

Thanks for shining a light of things. A single element serializes to this:

<SOAP-ENV:Envelope xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="https://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="https://schemas.xmlsoap.org/soap/envelope/" xmlns:clr="https://schemas.microsoft.com/soap/encoding/clr/1.0" SOAP-ENV:encodingStyle="https://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<a1:SerializableId id="ref-1" xmlns:a1="https://schemas.microsoft.com/clr/nsassem/RevitServices.Persistence/RevitServices%2C%20Version%3D2.0.2.6833%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Dnull">
<stringID id="ref-3">2ffe7cec-9741-4601-97ab-442840b4bec8-001158a3</stringID>
<intID>1136803</intID>
</a1:SerializableId>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

which is about 750 characters on average. That means that roughly for every 700 elements serialized to a dyn file you save something the size of an average novel :D

If we could save just the GUID strings maybe as json, that'd be a reduction of over 90%