> Thanks for your insight, Greg. I was surprised to learn that global > references each contain a copy of the data. This implies that each > time data is written to a global, each copy of that global must get > updated. The process sounds amazingly inefficient. Now I know why > globals are taboo in LabVIEW. >
The readers don't get a new copy until the next time they read. The deal is that the global could be updated once a second with various readers needing to hold the value they read for who knows how long. Since there could be three readers needing to hold a different value for ten seconds, that pretty much means there needs to be one global and one per reader. > I was also surprised to learn that control "references" are not like > data pointers, or object pointers, in this case. Thanks for pointing > out this error in thinking. This knowledge is sure to help me in > future projects. > > I have noticed that most of the NI code for interfacing with registers > and managing memory have a dll at the core. The function details are > handled outside of the LabVIEW development toolbox, precompiled and > self contained. It sounds to me that the only way to efficiently and > effectively get control over the memory is to write the code block (in > c or something) to manage the data the old fashioned way. It appears, > as I have anxiously suspected, there's no substitute for knowing how > to manage memory at the lowest level. > Each tool has its advantage, and C's advantage is that anything goes with memory. Integers, pointers to A, pointers to B, its all the same. The downside is that this lack of safeguards means lots of debugging and head scratching. LV can't do everything as efficiently as C can, but in the common case, you get the low level stuff written in C, accessable and usable from LV so that you get the best of both. This is true of most/all good libraries. Greg McKaskle
