Compiled code complexity

[wiebe@CARYA]

---

@altenbach wrote:

Note that this is local to the current VI and does not really depend on the number of VIs in the project (unless they are set to be inlined).

---

There is a dependency (arguably): the number of VIs is too low. That is, putting the right things in the right VIs will reduce complexity.

I once encountered a (customers) VI that wouldn't even load when migrating to LV11. It had a maximum depth of 45 nested structures, and was about 3.5 MB. Trick was to revert to the old compiler (won't tell how in this thread), just to make it open. The old (non-LLVM) compiler was a bit more forgiven, but a lot less fancy.

[JÞB]

A code complexity of 9 on 200ish vis should not be bogging down the compiler.  Period.

I would suspect that the SCC has a mix of source code and complied objects.  Try clearing the object cache and checking that all Development machines are set to separate source from compiled code.

By the way, with a single dev machine I once refactored a vi with a code complexity >80 in 2017 with the compiler optimization set to 10.  I did need to uninstall the TSVN Tool Kit. But, that was an OS issue.

[billko]

How do you get complexities so high?  Most of my VIs and subVIs are usually 1.0 or less.  Even the "busy" ones.

[JÞB]

---

@billko wrote:

How do you get complexities so high?  Most of my VIs and subVIs are usually 1.0 or less.  Even the "busy" ones.

---

Inherit them from "experienced" LabVIEW developers.   Bill, you COULDN'T write that.  Heck, it took ME too even read that!  Worse, with the race conditions from local and global abuse, the GUI only represented the desired system state--- no relationship to the actual system state.  Yes, it worked when I was done.

[Bob_Schor]

---

@Vishnu.R wrote:

I can't share my VI here. I have used subVI at most of the possible places.Project includes more than 200 subVI.

---

I'd not looked at the complexity of my code recently.  I took my most "complex" Project, where a Main VI can "spawn" up to 24 asynchronous Clone VIs, each of which consists of a main VI and 3 asynchronous "interior" VIs, everything tied together with Channel Wires in a Channel-analogue of the Queued Message Handler (I call this a Channel Message Handler).  There are about 160 VIs and sub-VIs here (about 70 in the Clone, around 90 in the Main and a lot of sub-VIs).  The Complexity of Main is 2.5, and the Complexity of the Clone (which consists of one CMH calling three other parallel loops, each of which is also a CMH) is 0.9.

All of these VIs have Block Diagrams that fit easily on a Laptop Screen.

Bob Schor

[BertMcMahan]

---

@JÞB wrote:

A code complexity of 9 on 200ish vis should not be bogging down the compiler.  Period.

I would suspect that the SCC has a mix of source code and complied objects.  Try clearing the object cache and checking that all Development machines are set to separate source from compiled code.

By the way, with a single dev machine I once refactored a vi with a code complexity >80 in 2017 with the compiler optimization set to 10.  I did need to uninstall the TSVN Tool Kit. But, that was an OS issue.

---

Jeff just to make sure I'm understanding you, are you talking about the Compiled Code Complexity in the File -> VI Properties -> Memory Usage screen, not the VI Analyzer's Cyclomatic Complexity, right? I just checked a fairly crummy top level VI and it has a Cyclomatic Complexity of 109 and a Compiled Code Complexity of 6.4. I can't even fathom what a CCC of 80 would even look like! I also opened one of my first, absolutely horribly written, massive spaghetti block diagrams and it had a cyclomatic complexity of ~150, but the CCC was only around 5.5.

[altenbach]

---

wiebe@CARYA wrote:

---

@altenbach wrote:

Note that this is local to the current VI and does not really depend on the number of VIs in the project (unless they are set to be inlined).

---

There is a dependency (arguably): the number of VIs is too low. That is, putting the right things in the right VIs will reduce complexity.

---

I was talking about the "compiled code complexity" found in the VI properties. This is "per VI". So, yes for any given overall task, there is a inverse relation, the more subVIs you have, the smaller the average complexity per VI. 😄 OTOH, you have more call overhead. 😉 It is a matter of finding the right balance.

[JÞB]

---

@BertMcMahan wrote:

---

@JÞB wrote:

A code complexity of 9 on 200ish vis should not be bogging down the compiler.  Period.

I would suspect that the SCC has a mix of source code and complied objects.  Try clearing the object cache and checking that all Development machines are set to separate source from compiled code.

By the way, with a single dev machine I once refactored a vi with a code complexity >80 in 2017 with the compiler optimization set to 10.  I did need to uninstall the TSVN Tool Kit. But, that was an OS issue.

---

Jeff just to make sure I'm understanding you, are you talking about the Compiled Code Complexity in the File -> VI Properties -> Memory Usage screen, not the VI Analyzer's Cyclomatic Complexity, right? I just checked a fairly crummy top level VI and it has a Cyclomatic Complexity of 109 and a Compiled Code Complexity of 6.4. I can't even fathom what a CCC of 80 would even look like! I also opened one of my first, absolutely horribly written, massive spaghetti block diagrams and it had a cyclomatic complexity of ~150, but the CCC was only around 5.5.

---

That was the cyclomatic complexity as reported bi VIA

[BertMcMahan]

---

@JÞB wrote:

---

@BertMcMahan wrote:

---

@JÞB wrote:

A code complexity of 9 on 200ish vis should not be bogging down the compiler.  Period.

I would suspect that the SCC has a mix of source code and complied objects.  Try clearing the object cache and checking that all Development machines are set to separate source from compiled code.

By the way, with a single dev machine I once refactored a vi with a code complexity >80 in 2017 with the compiler optimization set to 10.  I did need to uninstall the TSVN Tool Kit. But, that was an OS issue.

---

Jeff just to make sure I'm understanding you, are you talking about the Compiled Code Complexity in the File -> VI Properties -> Memory Usage screen, not the VI Analyzer's Cyclomatic Complexity, right? I just checked a fairly crummy top level VI and it has a Cyclomatic Complexity of 109 and a Compiled Code Complexity of 6.4. I can't even fathom what a CCC of 80 would even look like! I also opened one of my first, absolutely horribly written, massive spaghetti block diagrams and it had a cyclomatic complexity of ~150, but the CCC was only around 5.5.

---

That was the cyclomatic complexity as reported bi VIA

---

Ah, I think the OP is referring to the Memory Usage CCC, which tends to be under 10- a value of 9 in cyclomatic complexity is very low, but a 9 in compiled code complexity is very high.

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:

---

@altenbach wrote:

Note that this is local to the current VI and does not really depend on the number of VIs in the project (unless they are set to be inlined).

---

There is a dependency (arguably): the number of VIs is too low. That is, putting the right things in the right VIs will reduce complexity.

---

I was talking about the "compiled code complexity" found in the VI properties. This is "per VI". So, yes for any given overall task, there is a inverse relation, the more subVIs you have, the smaller the average complexity per VI. 😄 OTOH, you have more call overhead. 😉 It is a matter of finding the right balance.

---

Yes, exactly. Sorry if that remark came on to serious.  It wasn't.