Selectively disable auto compiling

[Daklu]

When I have large projects with lots of classes, Labview's edit time environment slows down to a painful crawl.  Almost every meaningful action triggers a recompile that gives me a busy cursor for 3-10 seconds.  My productivity falls off a cliff and I avoid making important changes in favor of the cheap hack.  (The dev environment has high viscosity.)

I often wish there were a way to turn off the compiler while I make a set of changes.  I'm not interested in the errors at every single intermediate state of the code while I'm making the changes.  I *know* the code will be broken after I delete some nodes or wires.  Let me turn the compiler off, make my changes, and then turn it back on for error checking.

I'm sure there are lots of different solutions to address this problem.  My preference would be to make compiling faster so it is unnoticable.  I doubt NI will ship me a new computer with the next release.  My second choice would be to stop loading all of the class' member vis when any single vi is loaded.  I vaguely remember a discussion about that some time ago and it wasn't practical to do that.  That leaves me my third choice--more control over what automatically compiles when I make edits.

It could be something as simple as Ctrl-Shift clicking the run arrow to toggle auto-compiling at the vi level.  Or it could be a right click option in the project window that controls auto-compiling for an entire library or virtual folder.  Either would be okay; both would be nice.  

(For that matter, it would probably be a lot cheaper if NI just shipped me a new computer...)

[Intaris]

Yeah, this would be cool, but make sure to auto-compile before saving the VI files or closing LV.....

[Daklu]

I agree saving should force an auto compile.

Having thought about this a bit more I have a slight modification...

Disabling auto compiling would prevent broken wires from appearing on the bd if you wired up two incompatible terminals.  That part is extremely helpful and very fast.  What (I think) causes the lag is when Labview traces wiring changes back through all the calling and called sub vis.

Instead of "disabling" auto compiling, restrict it to the block diagram I am currently editing.  That would preserve the type checking.

[JackDunaway]

This seems like a bandage, and does not address the root problem. Am I mistaken?

(Out of curiosity, could you please give specs on the computer that takes 3-10sec and some size metrics of your project?)

[Thoric]

I agree wholeheartedly! I'm working on a fairly large project and if I make changes to my FPGA code, it propagates the effect through a subvi heirarchy about 60 deep! This take forever and is really irritating. If I could just briefly suspend the background compiler, make my list of changes, then re-enable the compiler, I think I could halve my development time.

Thumbs up to this idea!

[AristosQueue (NI)]

Compile -- the generation of the assembly code from the diagram -- only happens when you save or hit the run button. I do not know where your slowdown is coming from, but it is not from compilation. Type propagation -- the process of figuring out the types of terminals and the error state of the VI -- runs after every user edit, but it does not span out to the whole hierarchy. It only propagates the local diagram (and only the part of that diagram downstream from your edit) unless the edit changes the conpane of the VI, which can trigger type prop on callers, but those edits should be relatively rare and should not span beyond callers to encompass your entire VI hierarchy. 

There are particular edits that can cause more wide-spread delays in the LV editor, but you're describing a slowdown on every edit. I do not know where the slowdowns you're mentioning are coming from, but a switch to turn off compilation and/or type propagation is not going to help -- what you're asking for is largely already implemented. If you have a project that is dragging down like this, if you can share the code, I highly recommend contacting an AE and filing a bug report, attaching the slow project to it. That way R&D gets a chance to see what actually is creating the delay and maybe ameliorate it somehow.

[Daklu]

@Jack

Had my understanding of the breakdown of compiling/type propogation been correct then yes, this would have been a bandage.  That's because I was under the impression all those checks were necessary for Labview to be gentle to new users.  If I can't remove the checks and can't speed them up without a faster computer (on another thread it was pointed out that compiling is a very serial process) then I'm left with a hidden switch so advanced users can temporarily disable the checks.  Not ideal, but the only viable solution I could think of given the constraints.

Since AQ pointed out that my request is already implemented by default, there must be something else going on that is causing the slowdown.  I'll see about packaging up my code and sending it off to an AE.

My project has:

11 libraries (some nested)

76 classes (all in libraries)

428 VIs (Almost all in classes)

Computer is a Lenovo Ideapad Y530.  Not sure of the cpu speed; maybe 2.2 GHz.  Windows 7 32-bit.  4 GB Ram.

There is some discussion of the problem on LAVA.

[Nitin_T]

@Daklu

After contacting the AE, could you post the CAR id back to this forum so that everyone can track the issue.

Also, a general band aid for edit time slowdowns (may not apply to your specific problem) is to break a critical path in your VI (resulting in a broken VI), make all the necessary edits and then fix the part you broke earlier.