LabVIEW
what would cause one read of a global be slower than another?
OK testing indicates that I stay with the LV2 version.
Here is a screen shot of my benchmarking.
Stay tuned!
Ben
Message Edited by Ben on 03-23-200611:33 AM
Hi Ben, Hi all,
This is what I call a great and very interesting thread... Thanks Ben for
sharing your experience and observations.
What surprises me is that you chose to use a global (wich in my opinion is not
the appropriate tool for this) just because of speed conciderations, am I wrong
?
And now, you aparently decided to come back to FGV - but still because of speed
conciderations...
Is you application such time critical that you need to worry about a fistfull
of u-seconds ?
I am not sure about how works global variables but I assume that it is
duplicated many times in memory and so I am not surprised that problems occur
when you read it from many different parts of your app.
Only concidering the description of your "stop process" I would have
chosen a notifier or queue, I think an empty queue would be nice in terms of
"coding style", no ?
An queue queue read in all your loop, with a "preview queue" to read
and get the "timeout" output to know if the loop has to stop ; like
this you can put anything in your queue that doesn't matter since it will never
be read, just the information that "something" is in will be the stop
source.
BTW, there are my results... I am really surprised that global are so fast to read and Q so slow...
Message Edité par TiTou le 03-23-2006 07:32 PM
HI Titou,
See my replies inserted into your text.
--------------------------------------------------------------------------------------------------------
This is what I call a great and very interesting thread... Thanks Ben for sharing your experience and observations.
[Ben] Thank you and you are welcome!
What surprises me is that you chose to use a global (wich in my opinion is not the appropriate tool for this) just because of speed conciderations, am I wrong ?
[Ben] Yes sir! I am devloping a "crazy" application. We are up 30,000 "channels" with sample rates that vary from 1-1000 Hz.
And now, you aparently decided to come back to FGV - but still because of speed conciderations...
Is you application such time critical that you need to worry about a fistfull of u-seconds ?
[Ben] Yes Sir! When completed, this application will have to settle arguements about which part of the system failed to what they were supposed to do and when. Portions of the 30,000 channels will be coming from descrete systems that need to interact with each other as specified. In the final phases all of the contituents of the system I will be monitoring will be syncronized via IRIG-B and crystal clocks.
I am not sure about how works global variables but I assume that it is duplicated many times in memory and so I am not surprised that problems occur when you read it from many different parts of your app.
[Ben] Good observation, stay tuned.
Only concidering the description of your "stop process" I would have chosen a notifier or queue, I think an empty queue would be nice in terms of "coding style", no ?
An queue queue read in all your loop, with a "preview queue" to read and get the "timeout" output to know if the loop has to stop ; like this you can put anything in your queue that doesn't matter since it will never be read, just the information that "something" is in will be the stop source.In addition, with a Release Q with "destroy queue" to false in each loop, you are sure that the queue will be destroyed only after all your VIs have read it... isn't wonderful ?
[Ben] Yes that is a valid approach but again see my comments above on performance. The dynamic loading of components into this application makes that approach a little more cumbersome. The top level VI will at some time become "fixed" while I will have to develop new components at a future date. I can dictate that the "Global stop" wil always be there when I have to deploy future components.
BTW, there are my results... I am really surprised that global are so fast to read and Q so slow... 
[Ben] Yes, a factor of 100 can not be ignored. That is why I broke my rule about "not using globals" just to pick up that performance delta. But like I said, stay tuned!
Ben
Final Update (?)
After testing and personally witnessing the results this is what we found.
1) Globals are still evil. Eliminating these got rid of "Finished Late" issue due to dragging windows around. The theory is that the global reads are using the UI thread.
2) One of the 600+ VI's was passing a bad "Period" value into one of the timed loop sub-VI's. This is what caused the "Finished Late" issue when that module was used.
3) The remaining failing module will be restructured to stream line its processing.
General observations:
1)Contrary to the benchmark work that compares the LV2 with the traditional global, there was very little difference between using the two methods. That implies (to me) that vey little of actual processing work involved determining if it is time to shut down. Concidering the problem the globals caused by running in the UI thread (not sure on this detail) the better performance of the globals was of no use.
2)It looks like the "Finished Late", "Expected End" and "Actual End" reflect the results of the previous iteration of the timed loop (This distrurbed the data flow paradigm part of me). 
Once again, I thank you for sharing your ideas.
Ben
