LabVIEW 2010 slow vi save performance

[AdamKemp]

We are aware that some large VIs can take significantly longer to compile, but our benchmarks have shown a corresponding significant improvement in runtime performance which we think is worth it. If the compile of a single VI is taking too long then I suggest that you make that VI smaller by creating more subVIs. You can probably even find some duplicate code in there to replace with a single subVI. Having a single large VI has multiple downsides already, so it's always a good idea to refactor. You'll find that it's easier to manage in addition to being faster to compile.

[rrawer]

Dear Adam,

Thanks for the clraification.

I understand that the performance increase is a big plus point.

However I woull still prefer to get a chance to influence that saving behaviour - in a large application with lots of user interaction, performance is often not a big concern (appart from a liminted numbe rof VIs maybe), however increasing saving time during development by a factor for 20 is a pain in my opinion, in fact for me it leaves teh question weather I stick to 8.5 or finally uopgrade to 2010. And I would really like to switch to 2010 becasue the separation of code and object data could finally make group work with source control work...

Anyway - an optional switch in teh Project or even better on the VI level would really make things easier on the development side...

Nevertheless I will try to schrink the VI, but I wonder weather it's just teh fact that there are a 100 cases in the eventstructure, which won't change even if I try to pack everything in subVIs...

thanks,
Rainer

[AdamKemp]

The nature of some of the architecture changes we made make opting out impractical. We replaced the entire backend of our compiler (the part that generates machine code) with one that does optimizations at a lower level than was practical before. Even without actually doing the optimizations the new backend just does more work than the previous one. Opting out would mean using our old backend, which would mean supporting and maintaining three separate backends (LLVM [the new cross-platform one] plus our old x86 and PPC backends).

Keep in mind that saving is only slower when we have to compile. If you refactor your code so that you don't have to modify the top-level VI often then even if we're still slow while saving it then you won't have to worry about it much because you won't have to save it as much. We'll only have to recompile it when you modify it directly or change something in its subVIs that makes callers recompile.

[johnsold]

Adam,

Thank you for the explanation.

Lynn

[rrawer]

Dear Adam,

To check your suggestions I did a simple experiment: Attached you find a simple VI constituting of an event structure, 50 buttons and 50 change value cases. 30 of the cases do simple calculations in a loop each, 20 cases do a value signalling event on another button.

If you now delete in case #1 (Button 1) one of the two for loops and waveform graphs and save then it already takes about 5 seconds to save (and the vi is only 80kb large). Again save the same vi in LV 8.5 is not noticeable.

In addition I checked the larger VIs and actually most of the event cases already are basically just triggering a sub vi and giving some input data - so there will not much to be streamlined. Comparing them to more complex Vis actually does not seem to make much of a difference in saving time.

I think this topic is a serious problem for anybody programming larger applications with user interactions. I don’t see how you could get around the user interface handled in one VI and if it’s not only constricting of a few buttons generating a 100 events is not uncommon. In this case you end up easily with code between 500kb and 1Mb.

A big convenience of LabVIEW so war was that you could build up the code function by function and right away test every added function with original data. For this reason (and certainly to prevent from code loss) I used to save the code frequently (so probably every couple of minutes or even faster. In fact the Strg+S is more or less happening automatically, which I noticed once starting to use LV2010 and wondering what just happened because 30secs nothing happened...)

Anyway - if I now have to wait 20 to 30 sec for every save on my main VI even if I save only if I want to run the application this easily adds up to 30minutes to on hour pure waiting time per day just for saving. And this is exactly what's happening - I tried it with three larger projects of mine and basically in every single one I end up with this saving time problem.

I don't see how a more complex application could be handled efficiently this way - and I really believe if you don’t find a solution for this compiler problem many people who were happy about many changes in LabVIEW in the past years enabling them to handle larger applications will have a big problem.

Don’t get me wrong - I’ve been using LabVIEW now since 15 years and still think it’s for me the ideal system which I want to use and which I am constantly supporting ever since even though people in the company keep telling me other systems nowadays provide more or less the same functionality then LabVIEW wand it’s much easier to get got programmes…

So I’d really like to keep using LV but this saving problem simply drives me crazy spending half an hour to an hour per day just for saving files. This is a drastic cut in programming efficiency and I cannot recommend any of my colleagues to use LV2010 in a bit larger applications (which in fact in our company every single one seems to qualify for).

I really hope you find a solution for this problem, because if there’s no other workaround LV2010 is simply not usable for larger applications – and I’m sure this problem will become big as soon as some more companies want to upgrade to LV2010.

sincerely,

Rainer

[StudioGuy]

It is not just large "VIs" only, but large applications in general. My main VI is 500 kB, but there are many subVIs which could be called from the main GUI, hence they are in memory, and thus I think being compiled too for any top-level save.

While I appreciate the complier improvements, those of us who "save their work often" see this is as a big impact to workflow.

Can we find a middle ground...

While I understand the compiler is always running and showing us our broken run arrows and such, only when we save is it doing the more intensive longer compile. How about if that complete compile operation only happened when the user tries to RUN a VI? (And, of course during the build process, etc.)

For example, when you make an edit to a large project, and don't save but still try to run, that's just what it does -- the compiler does it's thing and the program runs after the usual delay. That's just fine.

Is this a reasonable compromise, and it sounds easy to implement (it already compiles before a run, just don't compile after a save)? If so, I'm happy to submit this recommendation to the Idea Exchange.

Regards to all.

[AdamKemp]

Thanks for your patience. I think what's going on is that there are certain patterns in VIs which cause extra work during compile now (extra information to keep track of in order to be able to do optimizations). One thing that can cause that is cases in event structures and case structures. We knew these could be slower, but we didn't see any numbers during our testing as high as the numbers you've quoted. When I compile the VI you attached on my machine it takes just over 1 second. It sounds like it's taking 5 times that long on your machine.

That brings up the obvious question of how different our machines are. What are the specs on your machine (CPU, memory, OS, etc.)? Maybe we didn't see numbers that high because we didn't test on slower machines or machines with small amounts of memory or some other factor. It would be useful to see what kinds of machines users have the most problems with.

It would also be extremely helpful if you were willing to email me your top-level VI (the one that was taking 15+ seconds for you). Then we could do some more analysis to see if there's a specific performance tweak we could make for this kind of application. We could assume that the sample VI you attached has the same cause, but we know what happens when we make assumptions. 🙂

[StudioGuy]

Adam,

I assume your offer was directed at "rrawer" - but I'm happy to share mine privately as well. Not sure how to PM that, or if email, what your NI.com address is.

My main VI is exactly as you describe the potential issue, which I wouldn't expect to be to unfamiliar with large applications; that is, a master while loop running off a command queue executing various cases, and an event structure in the Default case for handling GUI actions - a fairly common design pattern.

I don't think machine specs, unless really poor, are the main issue. I have the same 7 seconds of save time (1 full second with LV 2009) on three separate machines I've tried, with different OS, different RAM, etc. Similar 3 GHz clock speed, however.

Let me know.

[rrawer]

Hi Adam,

As long as there's a chance that we find some kind of solution I'm more then happy to give any support.

The machine is a Dell Core 2 Duo E8400 at 3GHz and 4GB ram with an onboard Intel raid 1 running Windows XP SP3.
I think it shouldn't be a real performanc eproblem of the PC... 

I did an installation on an older P4 HT 2.8 GHz 3GB Ram. On that machine ist takes just a bit longer. However the large applications take about double the time then on my machine.

Well, there's one project that's a bit smaller but still takles about 20 to 30sec to save. That one I woudl feel more comfortable to send out the source code since the top level VI itself will probably be of not much help since most subvis woudl be missing. So if you let me know a non public upload for that or if you send me an email adress I could mail you a download linke then I yould upload you the whole project.

Rainer 

[AdamKemp]

Thanks, guys. It is a bit troubling that your machines are not slow and yet you're seeing such long compile times, so I think it could help a lot to see the VIs. Just to clarify, though, you are talking about saving a single VI, right? Not a save all?

You can send them to "adam {dot} kemp {at} ni {dot} com".

Thanks.