12-07-2006 03:40 PM
12-07-2006 03:47 PM
12-07-2006 04:11 PM
see this thread
http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=2362&jump=true
Where tst solicites replies to the Q " Re: Are globals really THAT evil? ".
Ben
12-08-2006 09:29 AM
After reading the thread about "are globals really THAT evil?" I'm a little confused. It said somewhere in there that the built-in globals are faster than LV2 globals but the regular globals make a copy of the data. Wouldn't that slow up the call of a regular global and make LV2 globals faster? Also, in my application, most of the globals are written to only once and read multiple times and the few that are written to multiple times, I laid out a sequence of events or made the VI front panel modal so that race conditions didn't occur. I guess what I'm really asking is this. Would changing the globals to LV2 globals improve the performance of my application and make it run a bit faster?
Jason
12-08-2006 12:33 PM
One other tidbit I really like about "functional globals" when debugging:
I can set conditional breakpoints based on numeric value in the code for the "Write" case, then trace back to find out just who the heck is responsible for writing the weird value at the wrong time. Very nice!!! Can't do that with native constructs like true globals, notifiers, queues...
-Kevin P.
12-09-2006 09:55 AM
Nice trick. I haven't thought about that one.
@Kevin Price wrote:
I can set conditional breakpoints based on numeric value in the code for the "Write" case, then trace back to find out just who the heck is responsible for writing the weird value at the wrong time.
12-11-2006 01:24 PM
One thing for sure when to switch to global variables is:
1) to have a pop-up panel for user inputs
2) run out of room on the calling vi, even when using tabs
But the big drawback of it is slowing down the processing time when they are called and in active state (passing data or in a loop). And YES, ALWAYS avoid using them if possible because local variables are ALWAYS faster, stack pointer inherently, common sense!
12-12-2006 08:23 AM
@napview wrote:
One thing for sure when to switch to global variables is:
1) to have a pop-up panel for user inputs
2) run out of room on the calling vi, even when using tabs
But the big drawback of it is slowing down the processing time when they are called and in active state (passing data or in a loop). And YES, ALWAYS avoid using them if possible because local variables are ALWAYS faster, stack pointer inherently, common sense.
I can't say I understood what you're saying, but I fail to see the relation between locals and globals. In general, using locals as a means of data storage is bad form - you're better off using wires as much as possible with the same exceptions which were described in the other thread for globals and a few exceptions which are only relevant for locals.
You are correct that locals are faster than globals (although I wouldn't jump to conclusions as to why, probably the locking is simpler to handle), but globals should be used when you want a global means of communication, not just because you run out of room on your FP. If you want to avoid running out of room, either use tabs and hide the controls or use wires instead of locals. In any case, both globals and locals have some disadvantages which can be overcome by using functional globals.
12-12-2006 11:30 AM