Understanding code complexity

[JackDunaway]

---

tst wrote:

Another option might be to farm out the compilation to a dedicated server (either your own or I think NI provides this as a service, although I don't know if that only applies to FPGA. You could also try asking Jack Dunaway who demonstrated working on Amazon's remote machines).

---

Yes, this can be useful if time saved exceeds setup cost and learning the domain and keeping an expert on staff who can hold the hand of the build server -- perhaps someone will develop a better solution?

In the meantime, I'm with Shane, trying to nail down the root cause.

Shane, I've had the best luck minimizing build times by inspecting and eliminating static dependencies. I've not attempted to characterize this with respect to the code complexity metric, but rather the VI hierarchy and linker information.

[Intaris]

Tst,

Reducing the compilation optimisation would certainly help our compiles but as most people, we'd like to be able to deliver fully optimised code and not make comprimises on execution speed.

This is essentially the crux of the problem.

I was unaware of the ability to outsource a non -FPGA compilation......

[Norbert_B]

I think there is some major misunderstanding on the topic. I hope that i can clear some things up without having a too deep insight on how LV determins code complexity for compilation.

1.) Code complexity != code complexity

When talking about code complexity, it is important to define if that refers to compiled or uncompiled code. I have the impression that most posters in this thread refer to the complexity of the uncompiled code, which is not the goal Shane is talking about.

Uncompiled code can be difficult to read aka. "complex", but the compiled version of this code could be rather simple. Experience shows that well written code, aka "simple uncompiled code" also results in a low complexity in the compiled code. But there are cases (and we probably see one here) where this dependency is not like this.

The number the VI settings show in the "Memory Usage" tab refers to the compiled code.

2.) What happens during compilation?

The LV compiler got reworked over time to use transforms for code optimization. You can get a quite detailed information on this here. Long story short: With LV 2010+, two optimization layers are available: DFIR and LLVM. Both layers might include information for compilation not only from the block diagram, but also the front panel (connector pane, ...). So a simple block diagram complexity (uncompiled code) does not necessarily imply a simple compiled code!

3.) Effects of "Enable Debug"

The option to enable debug for a VI prevents esp. DFIR from performing certain optimizations. It is possible, that this has an effect on the complexity of the compilation. Maybe you want to run a test with this option toggled.

4.) Other options of interest

Without any promise, the following options and structures can also have effect on the complexity of code during compilation:

• Reentrancy
• Inlining
• Required vs. Recommended Input (Connector pane, see 2.))
• Inplace Element Structure
• Timed Structures
• Parallizable For Loops

just my 2 cents,

Norbert

[Intaris]

Setting Debugging to "False" drops the compiled complexity to 5.4.

I suppose I'll just ahve to live with the code as is (I don't really have a choice).

What effect does putting code in Sub-VIs have on code complexity.  Non.inlined Sub-VIs don't count towards compiled code complexity, right?  If I put more code in sub-VIs, will that make compilation "easier"?

[Norbert_B]

---

@Intaris wrote:

[...]

What effect does putting code in Sub-VIs have on code complexity.  Non.inlined Sub-VIs don't count towards compiled code complexity, right?  If I put more code in sub-VIs, will that make compilation "easier"?

---

Hm, don't think that there is a rule valid for every case. Reason: Inplaceness.

Static subVIs include inplaceness information which is relevant for the caller. That is btw the reason why the caller has to be recompiled if the subVI is changed. Depending on this, the complexity could stay at a similar level. But for most cases, i would expect the complexity of the caller to decrease a little. Can't give figures though....

Norbert