Option for Data Name as Variant Attribute
Issue #105
new
I was playing with the BlueSerialization library and found that one of the main sources of slowness was the use of Set Data Name, which unflattens the variant, sets the data name in the type descriptor, and then unflattens the data back to variant.
I propose the following (which improved performance in the BlueSerialization library by a factor of 4x):
Inside of Flatten to JSONtext, check for a Variant Attribute called JSONtext.DataName and, if found, use that vale instead of the data name obtained from the variant's Type Info.
This would allow a caller of Flatten to JSONtext to set the variant data names using these variant attributes (which is fast) instead of having to set the data name on the actual type descriptor of the variant data (which is slow).
Comments (7)
-
-
repo owner
I wish NI would finish the missing Variant API functions, such as Set Name.
-
repo owner
Quick Question: are you sure you need the name set? Note that “Variant to Data” ignores names completely, so if one is converting to non-generic data at some point then you shouldn’t need to set teh name.
-
repo owner
Did a quick test of how much this would cost other code not using it: looking for a (not there) attribute is 0.04 us, as compared with the “Get Type Information” call which is 2 us. So this would add only 2% overhead.
-
I’ll look closer at the code to see why it needs the data name set.
-
I think the issue is that the BlueSerializer has a “Convert Anything to Variant” that first converts all LVClass instances to Variants inside the outermost Variant, and then calls its Variant to Text (which has a JSONtext implementation) on the variant.
I think that this is rather suboptimal compared to traversing the variant and converting each LVClass to a Cluster which is then immediately passed to JSONtext. I think I see a path forward for this…
-
See Issue 107 for a feature that would be helpful in solving this.
- Log in to comment
This is Jim, by the way who posted the above