Highlight Common Performance Issues

[DFGray]

It is very common to build an array or string in a loop using the Build Array or Concatenate String primitives. Unfortunately, while easy, this also incurs a large performance degradation (see this post for some examples) and this is not communicated to the creator in any meaningful way, other than slow code. I propose changing the primitive appearance in some obvious way to show that a performance degradation is happening. This would only happen if the primitive was in a loop, since these functions are a normal part of LabVIEW programming.  Some possible methods of showing issues:

1. Change the border of the icon from a black line to an alternating red and yellow line (for an over-the-top effect, make it "crawling ants")
   
2. Change the background of the icon from light yellow to dark red, while changing the glyphs to white, so you could read them
   
3. Double the width of the border and make it red instead of black
   

Accompanying any of these would be a mouse-over or pop-up to explain why the colors changed. The change would also be explained in the context and primary help. I would definitely want a switch, probably in Tools->Options and the labview.ini file to turn the behavior off for advanced users. New users would see the change and should be able to find out why it is occurring fairly quickly. The help files for the nodes should give alternatives for using them in a loop, such as the post above or replacing a Build Array with a conditional index.

The majority of the problem comes from Build Array, Delete from Array, Insert Into Array, and Concatenate Strings, so an initial pass at this problem could target them only. The Build Array and Concatenate Strings issues could be largely removed by using compiler optimizations similar to the ones currently being used for the conditional index, although algorithm changes by the developer can lead to higher performance than the generic case (see link above). The Delete from Array and Insert Into Array issues are usually solved by algorithm changes on the part of the developer, so an indication of an issue would be useful.

[AristosQueue (NI)]

> As often happens you are twisting my comments around.

That's certainly not my intention. I don't know how to assure you that the compiler *is* a major area of investment for us. We push that team to be as large as we can make it without completely starving other critical areas. I believe that the desktop/realtime compiler team is the second largest subgroup within LV R&D, second only to the FPGA compiler team.

> "If you are going to do it for us, please do it right."

We try. If you want control, don't use a managed language. LabVIEW, C#, JAVA, Haskell, Lisp -- the compiler is in charge of the final code layout. You want C code for that level of fine-grain control.

[Darren]

With all this talk of VI Analyzer tests, I figured I should mention that we currently have a test that detects the scenario Damien describes for Build Array and Concatenate Strings...it's the Arrays and Strings in Loops test:

[johnsold]

Thank you, Norbert, for pointing out that the VI Analyzer is not a substitute for things which are included with LV.

Perhaps the place to start is to put good descriptions of the relative performance and suggested choices for code structures into the help. Particularly for the functions/primitives identified by Damien as the starting point.  Include a little flag/comment in the Context Help and a more comprehensive discussion linked through the Detailed Help.  Of course we all know that many of the people who need the help the most do not read the help files, but this is an area which could provide a substantial improvement (1) at little cost to NI, (2) without risking breaking any exisiting code, and (3) while encouraging a broader discussion of the merits of more intensive changes.

These kinds of performance issues are generally poorly documented at present (across all LV functions). Adding a section to the help on performance or optimization (or a link to a white paper, or whatever) would be useful in general.

Lynn

[AristosQueue (NI)]

johnsold:

> the VI Analyzer is not a substitute for things which are included with LV.

Luckily, LabVIEW 2014 Pro will include VI Analyzer. Don't tell anyone... it'll be announced in August. 😉

I would much rather "document" these things by putting them in VI Analyzer instead of help files because many times there are conditions under which a common performance issue isn't actually a performance issue, and trying to document the myriad exceptions just makes people needlessly avoid a given function. (Witness the exchange between me and DarinK about the Insert Into Array node... a simple misunderstanding of his comments made me think that the Insert Into Array node had a serious problem.) VI Analyzer can check the user's specific code and only call out issues that really are issues for that user.