LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BUG: Build specification, Debugging

Yamaeda_0-1790343809133.png

 

I assume _Enabling_ it will hamper optimization ...

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 1 of 5
(339 Views)

@Yamaeda wrote:

Yamaeda_0-1790343809133.png

 

I assume _Enabling_ it will hamper optimization ...


Yes, but disabling it does not ensure full optimization, just like it says. That's how I read it.

 

The help does not say anything more about how "Enable debugging" affects optimization or what else to do to ensure it though.

Certified LabVIEW Architect
0 Kudos
Message 2 of 5
(221 Views)

Fair enough, so how _does_ one get full optimization?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 3 of 5
(194 Views)

You can try unchecking debugging

 

In the Source Files Settings ->

mcduff_0-1790964074570.png

 

This next one is a bit dubious, not sure if it works. You would add this to your Pre-Build Actions. It sets the compiler to the highest level of optimizations. (You can also change this in the Options >> Environment Setting and then do a mass compile on your project.)

 

mcduff_2-1790965568067.png

 

0 Kudos
Message 4 of 5
(45 Views)

Hi

 

mcduff found an interesting property App.CompilerThreshold.

 

It is still mentioned in the manual apparently, but it refers to a concept that is no longer implemented in the compiler.

 

I had trouble with the new optimizing compiler introduced in LabVIEW 2009 32 bit which would completely eat up all available memory and then die, when building an exe from a complex VI.

 

I send them my code and NI introduced the hybrid compiler in LabVIEW 2010 SP1. It worked by introducing this compiler threshold concept deciding whether the code should be compiled with the old legacy compiler or the new optimizing compiler. And NI has trimmed the default to solve my problem.

 

The hybrid compiler worked splendidly for years up to LabVIEW 2019. The hybrid compiler was removed in that version because NI wanted to get rid of dual development path complexity and stating that the new compiler could handle everything. It could not. In the following versions NI tried to improve the compiler.

 

But LabVIEW 2018 SP1 is still the final version to use for handling complex VI's in 32 bit.

 

Someone within NI should review that manual section.

 

Regards

 

PS : If you ever write complex VI's and runs into this memory problem, look up other entries written by me on the subject. There is more to the subject.

0 Kudos
Message 5 of 5
(20 Views)