A thought on Style for the sake of Style, and a question: Where to wire constants?

[Broken_Arrow]

Lately, I've been trying to hone in on aspects of Style that effect my program's performance, and ignoring stylistic niceties in the sake of meeting deadlines. For example, Local Variables: if they work and don't cause race conditions, what the hey? I used to break my back to use as few locals as possible, but after Profiling some vi's, I've found I can live with 50mS delay here and there. Same for the "one page diagram" idea. Most of my programs take up two screens, while still using several sub-vi's! I've even gone back to using sequences after swearing them off a year ago. Where's the break-even point of using excellent Style and keeping your job?

Now for a question that I can't s
eem to profile my way into an answer::
Most of my programs run in one large loop and use Cases to run events. Many items require constants. Does it make much difference to place these constants OUTSIDE the loop? I'm assuming a constant of 12093.0092 may take more time and memory than, say a boolean True constant or a Not A Path constant. Any thoughts?

[Jim_Kring]

The LabVIEW compiler is getting pretty smart and will perform "constant folding" which causes calculations based on non-variable inputs to be calculated at compile-time and the results used as constants at run-time. You probably don't need to wory about constants, inside of loops... I don't 😉

-Jim

[Broken_Arrow]

No wonder the Profiler didn't pick up any real advantages! Thanks Jim.

[Peter_Blume]

Hello. In regard to the first part of your question, it's very important to remain productive and meet all of your deadlines. You can maintain good style and obtain efficient performance and improve your productivity by following some simple guidelines. One such guideline is to use a state machine architecture for most of your top level diagrams. With a state machine, you can avoid local variables by passing data in shift registers, and reading or modifying the data within the appropriate states (frames of the case structure). You also conserve block diagram space by breaking your application into snippets that each fit within one frame of your case structure. Best of all, you can easily expand your application as needed by simply adding more frames to the
case structure and enumerated type definition.
To quickly create a state machine using LabVIEW 7.0, choose the Standard State Machine Template from the New... dialog, under Design Patterns.
For more simple style guidelines, view the presentations at the following link: http://www.bloomy.com/Resources.htm

[Broken_Arrow]

Thanks Peter. I've hit your site a few times in the past, thanks for so graciously sharing the info.
My programs tend to be one huge loop, with lots of T/F case statements. More ofthen than not, the False statement does nothing. The GUI is usualy intensive, and the core program basically comes down to "if button B is pressed do the stuff inside this case", which tends to be Serial Writes, maybe a Serial Read, but Mostly front panel updates and file updates. I'm thinking this may lend itself niceley to using enumerated type definitions, which I've never used. Maybe next time, schedule permitting.
BTW, I use 6.0.2. Funds is low!