Leaderboard

Actually the memory space issue was the original original reason we moved to dataflow for what eventually became DCAF. Early concepts for that library involved sharing CVT tags between plugins, which got replaced with the calling process being responsible for sharing the values via dataflow. The other big issue is that if you use a global variable, like the CVT, you run into the problem that reads and writes are not coherent for sets of values...that is, if you wish to write the cluster {value=1, time=blah, accurate=true} that would be 2 or 3 separate write actions and a consumer wouldn't necessarily know that all values were from the same 'sample' if they were read out. Having the DCAF engine orchestrate plugin calls and act as the synch point for large data sets was also a driving factor. The implementation doesn't really preclude use of the CVT (I don't know that its ever been used, but I made a CVT-based engine at one point), its just that when you have a single labview process passing data around it makes more sense to use dataflow. As to performance, all the accesses are simple subroutine-priority FGV accesses so an individual read is pretty quick. If you knew what values you want to use up front you'll definitely get more better performance from a set of DVRs of clusters -- the locking is equivalent, but you solve the coherency issue above, you can create as many separate and distinct locks are you might wish, and with 2017 you can do parallel reads. The CVT is geared towards more dynamic situations. The slow part of the CVT implementation is the lookup (name->index). Theres a variety of 'advanced' functions to let you look up the index of each value early in the run of your application which brings performance back to just a few checks and then the FGV read operation which is quite fast. In general, the number of 1000 was always kept in mind as an intended number of tags. It can of course go much higher, but I think trying to keep 1000 individually named global variables in your head is hard enough, let alone more than that. Because it is a FGV-per-data-type, you will by definition eventually run into contention issues but thats going to be dependent upon your application. The alternative implementation I've seen is using queues (https://lavag.org/topic/14446-viregister/?page=1) or notifiers. If CCC is your main interest, something more standard like OPC UA might be a better fit.