Improve Diagram Disable performance

[MGiacomet]

Adding a Diagram Disable to NOT run some portions for the code shoulg NOT increase execution time.

I could understand it, while running under development mode, but when building the VI into an .EXE, that's preposterous!

Please fix Diagram Disable so that by adding one to NOT run some code, does not increase execution time.

[crossrulz]

Any complaints about the Debug Optimiations not being in an executable should be done here: Add an option to disable debugging/enable optimization when building application

[AristosQueue (NI)]

> This is the most "head-in-the-sand" posting from NI!!!

Really? The most? Clearly you haven't read all of my posts. 🙂

But let me try to explain the nature of this sand and see if htat helps.

> What??? Do you expect the user to manually turn debugging OFF on (my case) 4000 VIs????

Yes and no.

Yes, that is the current expectation.

No, no one is saying that is ideal behavior, merely that it is the current behavior.

Your original idea was to fix the compiler, claiming that there was a bug in the compiler. There is not a bug in the compiler. Thus the idea was declined.

You have a separate point about how that debugging is controlled. You filed a different idea to address that. That one is open (and gathering kudos). I back that one fully and hope you keep pounding that drum. Pretty much everyone agrees that this could be improved, there's a wide gulf between those who think this is an obvious necessity and those who think this is a nice-to-have-but-we-have-other-priorities-for-developers-to-work-on.

I'm on the side of "obvious necessity."  But it isn't head in sand... it is differences in perspective about priorities of development.

[JoshuaWalker]

> No, no one is saying that is ideal behavior, merely that it is the current behavior.

Is this not the point of the idea exchange - for the community to suggest improvements on current behaviours that will make them closer to what is ideal?

> Your original idea was to fix the compiler, claiming that there was a bug in the compiler. There is not a bug in the compiler. Thus the idea was declined.

While I cannot speak for MGiacomet, as far as I can tell the original post never said that this was a bug and instead stated that is was something that should be fixed (as in "do the necessary work to improve or adapt something")

Also as a programmer there have been many times when I have received a bug report for something that while technically not a bug is definitely a behaviour that should be changed

> ...the diagram disable structure will introduce performance hit because the structure node -- any structure node -- introduces a diagram break in order to allow execution highlighting to behave properly.

Because the disable diagram disabled cases will never highlight shouldn't the behaviour be changed to make use of this knowledge and instead make an exception treat the enabled case as if the diagram disable structure was not there?

> ...it is differences in perspective about priorities of development.

Because the idea exchange uses a 'Kudos' rating system to see where the community puts an idea as a priority, shouldn't this idea be kept to see where the community puts it as a priority in development?

[AristosQueue (NI)]

> Is this not the point of the idea exchange - for the community to suggest improvements on current behaviours that will make them closer to what is ideal?

Yes... and that's why the *other* idea is still open. This idea is not.

> Because the disable diagram disabled cases will never highlight

They will highlight. The interior of the structure won't unless there's an enabled case, but the structure itself does.

> Because the idea exchange uses a 'Kudos' rating system to see where the community

> puts an idea as a priority, shouldn't this idea be kept to see where the community puts

> it as a priority in development?

No. There are ideas we won't consider regardless of the number of kudos because of the secondary impacts of those ideas. This is one of them.