LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

How to keep large Labview project optimal?

TroyK wrote:

- maybe using data value references to pass big clusters (controls) into VIs? This will not help, (a) it will create more data copies and also slow down execution because (b) reading data from front panel objects via references and property nodes forces it to use the user interface thread.

(a)  I must not be understanding what you are saying, because DVRs specifically do not create more data copies.  Branching a DVR wire copies the reference number, not the data the reference points to.

(b)  Yes, reading data from front panel control references does go force execution through the UI thread.  I don't think I've ever heard of anyone bundling control references in a DVR.  I suppose it could be useful if the control references themselves are expected to change, but I don't think andrej intended to create a DVR of refnums.
0 Kudos
Message 11 of 14
(1,384 Views)

I have a project of about 1200 VIs that takes about 4 minutes to open from Source Control. My takes about 5 min to load.

It seems to take ages to load each of the LVLIBs each and every time. I agree, that is why I was thinking making dlls from my libraries.

The top level VI takes about 10 seconds to load. My takes about 20 s.

As rolf said, vi count isn't a great way to evaluate project size.  One of my current LVOOP-based projects has ~1k vis occupying ~30 MB of disk space.  In LV2009 project load time is ~10 seconds.  My top level UI vi opens instantly.  Granted I'm working on a pretty high power pc, but it's not *that* much better than yours.  (Unless you're developing on a x386.)

[From my earlier post]

"One way to check how interlinked your vis are is to open a new project and add a vi exposing a component's functionality. Then go expand the dependencies branch and see how much of your project is included. If the dependent vis are limited to those that are part of that component, you're probably good. If the dependent vis include other components or, in worse cases, all of your project, you've got dependency management issues."

Since you're already using lvlibs this is easier--you don't have to figure out dependencies for each vi but can instead focus on dependencies between libraries.  The VI Hierarchy window has the option in the toolbar to "Group Libraries."  That's a pretty good way to get a feel for how much interlinking you have.  You can also collapse the libraries by clicking on the little red triangle next to the library name, but the graphic rendering gets confused sometimes when you do that.

Old versions of VIs still referenced somewhere in the project explorer linked to missing SUBVIs? Not sure, I will take a look. Is there an easy way to find VIs that are not used by any other VI in the project?

Right click on a virtual folder containing source code and select "Find Items with No Callers."

0 Kudos
Message 12 of 14
(1,384 Views)

Daklu wrote:

(a)  I must not be understanding what you are saying, because DVRs specifically do not create more data copies.  Branching a DVR wire copies the reference number, not the data the reference points to.

Yes, quite right.

I assumed that because no mention was made of the original project containing Object Oriented code and because he used the phrase "pass big clusters (controls) into VIs" that Andrej was thinking about passing references to front panel controls into VIs and using them to write/read data.

As you correctly stated Daklu, If the data is contained in an object and you pass the data by reference, it will not make unnecessary extra data copies.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 13 of 14
(1,384 Views)

I realize it has been a couple of months now since this thread was active, but I have made an interesting discovery regarding edit time latencies.

If I expand the "Dependencies" item in the project tree, I get substantial latencies during edits. Even just switching between different front panels and block diagrams.

If I collapse the Dependencies item, after a second or two the edit time latencies disappear.

I would like to know if anyone experiences the same thing.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Message 14 of 14
(1,384 Views)