Code performance

[GraemeJ]

Is there a way of measuring code performance? In particular, can the performance of blocks of code within a vi be compared with one another?

The background to this question is that (and this is my first LV program) my code is a monster bowl of spaghetti. From previous advice from the forum, I am aware of one inefficient section but the performance was then OK. Now that the code has grown, it has slowed down and I would like to isolate the problem.

Regards, GraemeJ

[Aristos Queue]

In the VI's menus, choose

Tools >> Profile >> Performance and Memory...

[soupy]

QUOTE (Aristos Queue @ Jul 13 2008, 08:02 AM)

In the VI's menus, choose

Tools >> Profile >> Performance and Memory...

Beware, the above method uses a good bit of processing power in itself.

I can't use it because I don't have the processing margin to support the performance calculations. Please tell me if I'm missing something here.

To get around this, I run performance tests on individual subVIs before integrating them into the main VI. If I am trying to find the performance hog in the main VI, I probe it with tick timers. I like tick timers because they tend to be more reliable than than the windows clock. Note that tick timing will not work if your loop rate is greater than 100Hz.

I like to use the attached tick timer VI. Let me know if it needs any improvements.

[jgcode]

The VI analsyer toolkit may be of use?

[jzoller]

The profiler will work if you have subvi's. It won't work if you have monolithic code. If you need a quick subvi, you can highlight the relevant code section and Edit>>Create SubVI.

Note that it appears that the profiler can be blocked by the running process, so don't expect perfection. I've had a number of vi's that run a minute and a half, but end up totalling 30 seconds in the profiler.

VI Analyzer (if you have it available) is a static code analyzer. It will give you some tips on how to organize your code in more efficient fashion, but it's not really a performance tester.

Joe Z.

[Aristos Queue]

QUOTE (jzoller @ Jul 14 2008, 09:58 AM)

VI Analyzer (if you have it available) is a static code analyzer. It will give you some tips on how to organize your code in more efficient fashion, but it's not really a performance tester.

True. But several of the style tests have the effect of improving performance.

Here are some VI Analyzer tests that can find performance issues:

• Arrays and Strings in Loops—Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check timed loops.
  
• Coercion Dots—Checks the total number of coercion dots on the block diagram and the number of coercion dots on individual wires and compares them to user-specified limits.
  
• Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance.
  
• Wait in While Loop—Checks While Loops with front panel control terminals for structures or functions other than I/O functions that regulate the speed of the While Loop.
  
• Wired Terminals in Subdiagrams—Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. In order to avoid unnecessary memory copies, place control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram.
  
• Unused Code—Checks for unnecessary code on the block diagram.
  
• Globals and Locals—Checks whether a block diagram contains global and local variables.
  
• Reentrant VI Issues—Checks for uninitialized shift registers and non-reentrant subVIs in a reentrant VI. Because reentrant VIs maintain multiple data spaces, unexpected results can occur when using uninitialized shift registers. Additionally, parallelism could be inhibited if the reentrant VI calls non-reentrant subVIs.
  
• Array Default Values—Checks charts, graphs, and arrays on a front panel for empty default values. Saving non-empty default values inside charts, graphs, or arrays uses memory unnecessarily. When the VI runs, it overwrites values wired to indicators on the block diagram. If a subVI is using the VI, the VI overwrites values wired to controls connected to the connector pane.
  
• Empty List Items—Checks listbox, multicolumn listbox, table, and tree controls to ensure that they are empty. The VI populates the contents of these controls when it runs, so saving a VI with contents in these controls uses memory unnecessarily.
  
• Overlapping Controls—Checks that front panel controls do not overlap. The test does not analyze front panel decorations.
  
• VI Saved Version—Checks that the VI is saved in the most current version of LabVIEW.
  

[Gary Rubin]

QUOTE (Aristos Queue @ Jul 14 2008, 02:25 PM)

• Wired Terminals in Subdiagrams—Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. In order to avoid unnecessary memory copies, place control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram.

Is this a more technical way of saying that your connector-pane terminals should not reside within loops, case structures, event structures, or (shudder) sequence structures?

[LAVA 1.0 Content]

QUOTE (Gary Rubin @ Jul 14 2008, 02:37 PM)

Is this a more technical way of saying that your connector-pane terminals should not reside within loops, case structures, event structures, or (shudder) sequence structures?

Almost. Darren mentioned it http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=191642#M191642' target="_blank">in this thread where eventually Greg McKaskle came out of hiding and explained with one his classic summary lines "Clear as mud?"

Ben

[Gary Rubin]

QUOTE (neB @ Jul 14 2008, 02:45 PM)

Almost. Darren mentioned it http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=191642#M191642' target="_blank">in this thread where eventually Greg McKaskle came out of hiding and explained with one his classic summary lines "Clear as mud?"

Ben

Thanks, Ben.

I usually put my connector-pane terminals outside case structures, with empty arrays for which I don't want data, but I'd better make sure I've done it every time.

Gary

[jzoller]

QUOTE (Aristos Queue @ Jul 14 2008, 12:25 PM)

True. But several of the style tests have the effect of improving performance.

...

Thanks Aristos, that's much more concise than my statement.

I should mention that I've recently been using the VI Analyzer more frequently, and have found it to be an excellent tool. I expect it to save me literally days of mind-numbing work testing user submitted code against standards.

Joe Z.

[GraemeJ]

QUOTE (Aristos Queue @ Jul 15 2008, 04:25 AM)

True. But several of the style tests have the effect of improving performance.

Here are some VI Analyzer tests that can find performance issues:

• .
  
• Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance.
  

In my original post, one of the things slowing down the code was that debugging had been left on in Simple Error Handler.vi. When the main.vi was checked with VI Analyser, this was not detected (LV 8.5).

Regards, GraemeJ

[LAVA 1.0 Content]

QUOTE (GraemeJ @ Jul 15 2008, 04:16 AM)

In my original post, one of the things slowing down the code was that debugging had been left on in Simple Error Handler.vi. When the main.vi was checked with VI Analyser, this was not detected (LV 8.5).

Regards, GraemeJ

I assume you can instruct VI analyzer to ignore VIs inside vi.lib or user.lib.

Maybe you need to add those directories as well.

Ton