LabVIEW 2010 slow vi save performance

[rrawer]

Hi Adam,

Is there a chance that the SP 1 of LV2010 which is currently under Beta testing has any major improvements concerning the compiling time issues with large applications? (I got invited to the Beta test but don't know if it's worth while to install everything since you mentioned before that probably the SP1 won't help much with this issue...)

regards,

Rainer

[AdamKemp]

I can't comment on future releases in a public forum. If you are in the Beta program then you can check out the private Beta forum to discuss it.

[alecjcook]

I am a software developer, using LabVIEW as my language of choice to develop software. I find that I do a lot of saving and create a lot of large applications. This issue is causing me serious problems, along with many other 'features' of LV2010. Sorry NI, I don't like LV2010 😕

[CarstenPXI]

I spent some time with the LV group after NI Week looking at specific performance issues with our applications. I can only echo all the performance issues described in this forum. The new compiler can be significantly slower and the memory requirements during compile are also higher, which can really give performance issues when disk thrashing starts. Therefore we rolled back to 2009 SP 1. As John Pasquarette notes in this forum, this is an extremely high priority that NI is working diligently on, and knowing John and NI this is not marketing fluff. I have also asked some other very competent LV programmers if they have had performance problems with LV 2010, and they had not. Now their Design patterns are also very different from those described in this thread, i.e. Much smaller top level VIs and greater modularity. My guess is that 2010 SP 1 will make an good effort to get rid of the worst issues. Until then, my advice is simple--if you have significant performance issues with LV 2010, don't waste time looking for workarounds, to my knowledge, there are none that really help, but roll back to 2009 SP 1. We did and are happy again, and are confident that the dudes in Austin are working their tails off! Carsten Thomsen

[Yndigegn]

I am probably one of the support cases prompting NI to make the document  : http://digital.ni.com/public.nsf/allkb/BA4B9038D01F3C99862577CA004BE1AD.

I maintain a test system originating back to 2001. Until recently I have programmed it using LabVIEW 7.1.1 which is a particulaly reliable and fast LabVIEW version for development. But we are constantly running out of data memory so I was looking for better, that means newer, versions.

The problem with this application is that the main VI is huge. 18 MByte in LabVIEW 7.1.1. Containing hundreds of controls which needs to be made visible or hiddened as needed, and the complex coding also noted by NI. Editing this main VI is however instantaneous using LabVIEW 7.1.1 and run-time building is also fast ( ~ 2..3 minutes ).

LabVIEW 8.6.1 is the last version where I can still edit the main VI. The main VI shrinks to 2.5 MByte. The compiler apparently no longer do a complete syntax checking for every change so sometimes I have to run the application to get updated syntax status. But it works and the editing experience is still acceptable with occasional short freezes while some kind of reduced syntax checking seems to be done. Unfortunately there is only little performance gain using this version as compared to LabVIEW 7.1.1. In favor of LabVIEW 8.6.1 is that its code can be run unmodified in newer versions of LabVIEW whereas LabVIEW 7.1.1 code needs fixup due to the graph cursor change introduced in LabVIEW 8.0.

LabVIEW 2010 is completely useless for editing the main VI. If I change anything the editor goes havoc and freezes for many minutes and the memory consumption skyrockets to beyond 3.5 GBytes and stays there. It looks like a serious memory leak but who knows. For reference I run the 32 bits version of 2010 on Windows 7 64 bits which is why I have all that memory available. But eventually the application will usually still be able to run and I can save the VI(s) and restart the system and it behaves as it is supposed to.

Why then bother with LabVIEW 2010. Because it executes significantly faster that LabVIEW 8.6.1.

So my current setup is to develop in LabVIEW 8.6.1 and loading the application into LabVIEW 2010 where I can then make a run-time executeable. Loading and converting from 8.6.1 to 2010 takes about 30 minutes and run-time building takes another 30 minutes. I needed to modify the default built settings in order for the run-time builder to be able to built the application. Otherwise it will abort with an out of memory error. The settings needed to be changes are those that defines the degree of optimization. Reduce as needed.

What bothers me is the huge memory consumption ( the 3.5 GBytes ) during conversion and subsequent building. One feels like flying on fumes. And occasionally conversion and building does fail with LabVIEW vanishing without a trace.

I really hope that NI puts some resources into resolving this issue. They need to rethink if the compiler really needs to do a comprehensive compilation while editing or whether it should be postponed until a now-I-am-finished-editing-and-now-give-me-your-best-compilation stage. For most of the time I would be satisfied with the compiler in LabVIEW 7.1.1 if it gave me back the super fast syntax checking present in that version. And then only on command turned on all the bells and whistles present in the 2010 compiler.

Regards

[rrawer]

Hi Yndigegn,

Can you comment a bit mor ein detail about the performance enhancements of LV2010? What functions of the application are running faster and roughly how much?

Thanks,

Rainer

[Yndigegn]

Hi Rainer

The LabVIEW code is mostly glue logic interfacing to VISION. That means file loading of 60M+ pixels of floating point images and pixel manipulation beyond the functions present in VISION.

VISION 2010 processing seems to be 2..4 times faster than VISION 7.1.1 ( which is 6+ years old code ). Some of the performance boost seems to origin from a relaxed data check. Meaning that a NaN float value in data sent to a filter can cause VISION 2010 to kill LabVIEW instead of merely give a proper execution stop through the Error cluster as VISION 7.1.1 would do.

LabVIEW 2010 itself seems to be about 2 times faster than LabVIEW 8.6.1 on-the-average executing the same code. This is mainly image processing code consisting of "for loops". The lure of LabVIEW 2010 is the "promised" additional improvements using multiple processors when optimizing the LabVIEW code, similar to the OMP speed-up pragma for C code. But being unable to edit in an all LabVIEW 2010 environment then ..

Regards

[rrawer]

Hi Yndigegn,

For a highly computational task like image processing the speed improvements might be worthwhile the effort - however I would assume that LV8.x or LV 2009 would also give you a considerable speed improvement because they support the newer coprocessor functions that LV7.x did not know then. Also from my experience multi core performance of LV 8.5 is not to bad either - have you tried the speed improvements on a newer LV apart from 2010 (however obviously the change to the new vision version probably has the largest effect... ) 

Rainer

[Yndigegn]

Hi Rainer

When I started looking for more data memory ( my main objective ) the current LabVIEW version were 2009. I found it had a problem with missing text strings in at least one menu ring when loading and converting my very large main VI so I didn't trust it. The current LabVIEW 2010 has been fixed for this error and I have not seen other errors. So I trust it.

My options are hereafter either programming in LabVIEW 8.6.1 or LabVIEW 2010. Which leaves me with one choice ..

Regards

[Yndigegn]

For posterity ( for those who read about this issue in the future ) then the metrics for the large main VI mentioned above ( and the total test system ) with vi.lib statistics excluded are as follows :

9661 ( 43111)  nodes

777 ( 3263 ) structures

2787 ( 8365 ) diagrams

289 ( 2199 ) controls

106 ( 1137 ) indicators

235 ( 345 ) property reads

674 ( 1115 ) property writes

10 max diagram depth

440 user VIs