LabVIEW vi file size suddenly increases tenfold - compiler issue?

[Blue_Perfect]

I seem to have an issue with the compilation of certain vi's.

The file size (for this example) changes from 450kB to 40kB and back with any random small change, which - I assume - resets the compilation process somehow. Curiously the CTRL-RUN does not help here, even though I would assume it should be doing the same thing.

So I already know how I can reduce the file size, but can't yet get rid of the problem, as the memory consumption problem comes back if I fix the change.

So cycling: making a change - save - verify file size changed and it did - fix the code so that it works again - save - check the file size, and it's back to 10x again - does not work here.

Also adding a structure so that the deleted wire would go through different route does not help.

Has anyone else seen this? Could somebody explain what is going on here?

I would like to understand what is going on, and most importantly - how to prevent this.

---

- LabVIEW 2017 SP1 f3

- No default values in indicators

- Compiled code not separated from new files

- Code complexity 9.4 vs 0.0 after any change

- In the diagram I have Class structures linked as plugins i.e. not loaded to memory at this time.

- There are also some simple typedefs, but not much else.

- I have a lot of these, and can repeat the process at will

- Have rebooted the PC and restarted LabVIEW in between tries

[GerdW]

Hi Blue,

what exactly is the problem?

In "MemoryOK" there is no code in the VI, just FP and BD objects giving a total of ~220kB or 40kB (compressed) filesize.

In "MemoryIssue" there is code generated in the VI, adding another 1MB to the total of 1.3MB and resulting in a (compressed) filesize of 450kB.

What's the problem when the compiler generates ~900kB code and needs ~200kB for data inside the VI?

Or the other way around: depending on your VI that code size might be justified…

(When you need more detailed analysis you should attach your VI!)

[Blue_Perfect]

Hi Gerd,

the MemoryOk and MemoryIssue states are from same vi.

In between those memory states there is only one change: I delete one (any) wire.

Memory size is tenfold, and so is the time for opening the vi - which originally raised my suspicion on this problem.

It got so bad that opening a vi took > 2 minutes - and that's a problem I would like to solve.

Best regards,

Sami Karstén

[Yamaeda]

---

@Blue_Perfect wrote:

Hi Gerd,

the MemoryOk and MemoryIssue states are from same vi.

In between those memory states there is only one change: I delete one (any) wire.

Memory size is tenfold, and so is the time for opening the vi - which originally raised my suspicion on this problem.

It got so bad that opening a vi took > 2 minutes - and that's a problem I would like to solve.

---

A VI includes the compiled code, so if the VI can't compile the VI will ofc. be smaller, as in the case of a non connected wire.

Opening a VI shouldn't take 2 mins, but i've seen it happen if it's large, if it has lots of sub-vi's and anti virus goes bonkers, and in a couple of instances when LV tries to connect to some external resource it cannot reach. In the last case it help to disconnect any network.

If you attach the VI we can see if there's any other glaring issues.

/Y

[cstorey]

Sorry, missed the line where you said "- No default values in indicators".  But do the TypeDefs have default values stored?  Do you have lots of diagram disable structures?  

Does your VI acquire a lot of data?  Do you have a lot of plots?  Do you display a lot of array indicators?  Did you save the VI with a lot of existing data as the default settings for the controls and indicators? 

If you did that then a simple small VI which was a few kb might easily be 10x bigger because of all the data now saved with the VI.  If you saved lots of big arrays with thousands or millions of data points each then that's going to add a lot to file size.  Try clearing all unnecessary data from plots, controls, indicators and re-saving.

Craig

[Jacobson-ni · Accepted solution]

Code complexity of 9.4 is really high for an average VI. You have an architect badge so I'm assuming you're not going to have some enormous VI and if that's the case, I would look for any inlined VIs and see if they might be causing some problems.

[JÞB]

You have a lot of dead code.

[Blue_Perfect]

Thank you for the speculation without actually seeing the code, it helped me get to the bottom of this.

I learned from @Yamaeda that breaking the vi removes the compiled code from the vi, and reduces the size. Never actually thought about it, but that's how it would have to work. Not understanding that lead me to incorrect direction and lost time while trying to find the culprit.

@cstorey, I cleaned up all the all the disable diagrams, and typedefs were small so those were not it.

---

@Jacobson-ni wrote:

Code complexity of 9.4 is really high for an average VI. You have an architect badge so I'm assuming you're not going to have some enormous VI and if that's the case, I would look for any inlined VIs and see if they might be causing some problems.

---

Thank you Matt, that was spot on. I took the most complex sequence command as an example, because there the issue was most prominent. The top level function for accessing the class structure was set to be inlined. In the code there were multiple instances of this inlined function and it ballooned the vi code memory size about tenfold.

I learned a valuable lesson and the problem was solved, thank you all.

Best regards,

Sami Karstén

[thols]

...

I learned from @Yamaeda that breaking the vi removes the compiled code from the vi, and reduces the size. Never actually thought about it, but that's how it would have to work. Not understanding that lead me to incorrect direction and lost time while trying to find the culprit.

...

---

If you set the separate compiled code flag, the compiled code will not be a part of the vi (even when it is compilable). This setting is recommended to have, especially when using SCC, which I hope you are.

[Blue_Perfect]

Hi thols,

on the SCC question, yes, couldn't live without it.

On the "separate compiled code" the answer is no, not at this time.

However, I looked it up, and I feel that I have enough reasons to push for that change.

Thanks for the tip.

Best regards,

Sami Karstén