Compiler Optimization Scenarios

[FireFist-Redhawk]

Good morning,

I'm trying to come to a deeper understanding of how much the compiler does in the way of recognizing when BD constants are unused, or are connected to a tunnel but terminate after, and remove the "dead code" and not ever allocate memory for it. Look at the following scenarios. In which of them, if any, will the compiler remove them such that no memory allocation takes place in runtime?

Spoiler

This was spurned by our team starting down the path of HALs for all of our devices with simulation modes for all of them. And how best to ensure the child classes are always included as dependencies in the executable but without every class loading automatically, or the data from a class constant. My first attempt at the factory VI is shown, and here you will see that I do that by adding class constants in a case structure with False going to the selector. I've come to realize that in development, this loads every class, still learning. But I'm still not sure what the compiler does, if anything, to recognize that as dead code and just remove it entirely. And that led me down a more general train of thought of, if a memory allocation would take place in runtime for something like that. Appreciate any guidance on this.

Spoiler

[Intaris]

Fun addition: Which LabVIEW version, because it has changed in some recent versions.

[FireFist-Redhawk]

Ooooo fun stuff, we are currently on a combination of 2017 and 2020, hopefully to be fully upgraded to 2020 relatively soon.

[Intaris]

I think the behaviour of Cases 1 and 2 changed between 2017 and 2020, but I can't find the info right now when it changed. I remember people complaining that builds were not working because more code was being eliminated than before.

[Mark_Yedinak]

Is it possible for you to load them dynamically at runtime? You could use PPLs for your concrete implementations and build them as PPLs. Your virtual parent class would would also need to be a PPL which all of the child classes would inherit from. Store the child classes in a known location and then load the ones you need dynamically at runtime.

[FireFist-Redhawk]

Sorry I should've specified, our dev team has pretty much arrived at that exact solution you described, building the classes into PPLs and storing them on a network location, to be copied and pulled down automatically to target computers when a software needs them.

But that whole ordeal led me down a general rabbit hole of how the compiler treats different types of "unused" code. So that's pretty much what the intent of the post was, to get some info from people well-versed on that.

[altenbach]

---

@FireFist-Redhawk wrote:

For some reason you still have debugging enabled (your second picture), which also make a difference because the compiler needs to ensure that you can probe these wires, even if they don't lead anywhere useful. Once debugging is disabled, dead code is eliminated significantly more effectively.

(Of course debugging also gets typically stripped out when building an executable. Sorry, I don't have anything to contribute to your "classier" problem 😄 )

[FireFist-Redhawk]

---

@altenbach wrote:

---

@FireFist-Redhawk wrote:

For some reason you still have debugging enabled (your second picture), which also make a difference because the compiler needs to ensure that you can probe these wires, even if they don't lead anywhere useful. Once debugging is disabled, dead code is eliminated significantly more effectively.

(Of course debugging also gets typically stripped out when building an executable. Sorry, I don't have anything to contribute to your "classier" problem 😄 )

---

I was thinking more about runtime environment than development (I do strip debugging when building), but with debugging disabled in development I could see having this same conversation but in development. So if it's saved and not modified and debugging disabled and BD not open, in development environment it will also get ignored?