Variant Performance
Issue #46
resolved
Tests with Variants suggest could have higher performance:
- using swap values on Write of variant
- using VIM to do to-variant with explicit node (unclear why conversion at input of VI seems to copy)
VIM requires uping to LabVIEW 2017.
Comments (15)
-
reporter
-
reporter
Test of Performance (see Issue 46
→ <<cset 627ec6f00e79>>
-
reporter
Inconsistency in results, as if compiler sometimes does things one way and sometimes another. Backing off doing anything at this point.
-
reporter
Rediscovered this while looking at Queue performance. This is a VIM that avoids a copy (looking via DETK). It is the explicit To-Variant, rather than implicit, that does it.
-
reporter
Performance experiments suggest avoiding the DD Read Label functions, especially teh possible getting of the name in a Variant.
And Note that using a VIM, as in the last post, will lose the Variant name, so a Label must be written explicitly.
-
reporter
Consider adding a U8 Enum to MSG.lvclass, to identify message type, avoiding DD overhead in getting Label and Error.
-
reporter
With
#55, upgrade to 2017 and work on these. Start with Write VariantMSG:
-
reporter
I have used Swap in the VIs writing label and Reply Address. Label is usually a constant, so a copy will happen anyway, but Reply Address is sometimes a dynamically created complex Object, so this may help with small messages.
-
reporter
Also “Add Translator”, “Add Attachment”, etc.
-
reporter
Starting on VIMs for Write Message and Extract (rename Extract to “Read” or “Open”?).
-
reporter
Made a new “Message Type Enum” with DD Call, to faster identify Registration and Error Messages. First Use in Registration.vi
-
reporter
Turns out that indexing a new Array will copy the elements (this seems stupid but is verified by DETT). A place where this was slowing this is in Redeem Array of Futures. Change Made:
-
reporter
Tests show TCP stuff is a nightmare of data copies: more than 10!
-
reporter
-
reporter
- changed status to resolved
2.0
- Log in to comment
Testing done in 2017 and 2019 with 100MB strings. Need to look at smaller but more complex data types.