Postpone compiler optimizations until a run or build

[StudioGuy]

LabVIEW continues to evolve into a more optimized programming language through many under-the-hood compile optimizations, and LabVIEW 2010 brings the compilation improvements to a new level. However, these optimizations currently happen every time the user saves a VI or perfoms an undo. In the past, this would only take <1 second, but with LabVIEW 2010 there are several scenarios where each save of the same VI now takes 7 seconds, with reports of other VIs taking 15, 30 seconds or more.

SUGGESTION: Postpone compile optimizations until the user presses RUN, performs a build, or similar operation.

RATIONALE: Compiler optimzations are not necessary during edit time where a programmer is just saving their wiring progress, and anyway multiple edits can change the prior optimizations. The optimization of code is only necessary when the user is ready to run the VI in some fashion (in LabVIEW, in a build, etc.). At that time, the user is certainly happy to wait for the improved run-time performance.

[Intaris]

But doesn't mean we'll end up with broken wires when trying to run an otherwise non-broken VI?

Whyt I mean is, will we be able to make edits which SHOULD break the VI but won't until we hit the run button?  Will the delayed feedback for a VI-breaking operation not lead to confusion?

[StudioGuy]

I'm only addressing the compiler optimizations.

The LabVIEW compiler must always "be running" which is what shows our broken wires and such. I am not proposing changing any of that.

I am proposing that when you save a VI, the compiler currently performs many optimizations for run-time which have no edit-time necessity. Thus, save the optimizations for when they are needed (run, build, etc.).

When you try to run a VI, it will perform compiler optimizations if necessary (they haven't been done yet) and save that object code to the VI file and then run the optimized VI.

See some of NI's comments from Adam Kemp at:

http://forums.ni.com/t5/LabVIEW/LabVIEW-2010-slow-vi-save-performance/td-p/1223632/page/2

Regards.

[Intaris]

Ah, you don't want to stop compilation, only optimisations?  I wonder how much time this would save in reality.... Question: Do any of these optimisations have side-effects which could make a step like this dangerous?

[AristosQueue (NI)]

> However, these optimizations currently happen every time the user saves a VI or perfoms an undo

Compilation happens at load, save and run. It does not happen at undo. Autosave, which might happen while you are working, does not trigger compile.

> The LabVIEW compiler must always "be running" which is what shows our broken wires and such. I am not proposing changing any of that.

The LV proptypes system handles checking wire types, etc, while you are editing. This is not the same as the compiler which actually generates assembly code. In a text compiler, it's the equivalent separation between syntax checking and code generation.

[StudioGuy]

Yes, only compiler optimizations. And, not stop, just postpone until run/build.

Folks with large VIs and more complex programming structures are seeing VIs which used to take <1 second under 2009 and prior, now take 7 seconds (me), and 15 to 30 seconds for others as I noted in the intro. See some of the comments in the quoted forum thread.

It may not impact the majority of users, but for some large application developers, 2010 has been quite an impact for edit time when a user wants to frequently save work, or perform an undo.

[StudioGuy]

Not sure I agree that it does not apply to undo.

For one undo after a save, I agree.

But, perform two edits (delete a wire, delete another), press control-Z, wait 7 seconds (in my case) for that most recent wire to reappear.

I can ask Adam at NI to check that too, so that it's not just some other issue.

[rrawer]

Hi StudioGuy,

Your suggestion is certainly a better compromiose then nothing - but still I think waiting in large applications up to 30 seconds before testing for a small change is still verry annoing and time consuming (For me at least I like to use contatnt testing of sub functions which decreases design time since there is allways testing of functionality on a sumfunction level - So usually I'd say for teh main developing time I woudl think that in 50% of teh cases I woudl still have to wait a long time...

[StudioGuy]

Aristos, I did receive confirmation that the delays I am seeing in Undo are a different issue being worked separately. Just an unfortunate cooincidence of similar timing delays.

So, yes this should focus on just the save actions.

Thanks!

[DJed]

Optimizations are a minor component of the compile process currently.  The savings on turning off optimizations during save would not be the panacea you are looking for.  The problem is that the file you are saving is presumably a unifile (i.e source and compiled code are saved into the same file) in which case it will always require compilation to save as you are editing.  If you are using a large project, you probably want to check out the feature in LV2010 that lets you separate your source code from your compiled code.  This lets you save your source code as often as you wish and use source code control efficiently.  Then compilation would only occur when you want to run.  See http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/saving_vis_compiled_code/.

[pavanb]

You have my vote.

https://decibel.ni.com/content/polls/6634#comment-35232