Improve Diagram Disable performance - Repost

[MGiacomet]

Attention NI: Please DON'T summarily close this idea as you did with this one

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3254487#M344...

Users are still commenting!!! This is a BUG!

Repost:

Adding a Diagram Disable to NOT run some portions for the code should 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.

[X.]

AQ told you to use the fine grained timing VI. I asked you to post snippets.

And we are talking about less than 1 ns difference per loop...

[Intaris]

While I agree that it's futile to re-post a declined idea I don't like the "it's only X time per loop" comment.  It is a difference where no difference should be present.

Having said that, the entire problem is solved by a different idea (from the OP no less) for allowing the build spec to actively disable debugging.  So for that reason, this idea seems pointless.

[X.]

It is not about debugging, which pretty much everyone, including AQ, agrees doesn't go well with executable releases.

You are getting confused by two different posts. This one is about the Disable structure and was dismissed by NI R&D after internal testing.

The 1 ns difference might not survive statistical study, or using a better timing function. And vetting by others, which I would be more likely to do if I was provided with a snippet.

[Intaris]

Until the effect is verified, I'm going to take the "official" stance that it most likely has to do with debugging being enabled.......  Otherwise it's a bug, not an idea.

The problem with disabling debugging in these examples is that it will probably discard the code inside the for loop entirely since the values don't go anywhere.

[AristosQueue (NI)]

I did not summarily close the idea. I (and others) tried to verify the claim. We could not replicate the bug. The timing is identical in all of our trials once debugging is turned off, once you account for stable system. If you truly believe you have a bug, please go through an AE so you can talk them through steps to replicate.

[X.]

Here is a version with High Resolution Relative Second.vi used instead of the Tick Counts primitive:

On my computer (2.3 GHz i7 MBP 2014 running Windows 7 64 bit, LV 2015 64 bit), I see major fluctuations from run to run, and no obvious difference between with or without a Diagram Disable Structure [DDS] (Debugging Off and Optimization set to 10).

To look at some statistics, I wrapped this into a loop and ran it (one of the indicators is a Waveform Graph):

Results after 1,000 iterations:

• Debugging Off

      A: without DDS: 16.68 +/- 0.62 ms per Iteration (i.e. execution of the code within the sequence structure, which itself involves 100M iterations). Notice the fluctuations:

      B: with DDS: 15.78 +/- 0.49 ms per iteration. Still some major fluctuations:

So on the face of these results, using the DDS speeds up things. However, because of these fluctuations, I wouldn't be surprised that another test run at another time would result in the opposite ranking.

• Debugging On

      A: without DDS: 122.61 +/- 1.40 ms per Iteration. Still a lot of fluctuations:

Be careful that any use of another app may affect these results. For instance, here is an example of me switching to my browser to write something on this thread while running the test. Notice the weird jump around the 200th iteration when that occurs, and the subsequent slowdown:

I noticed a similar jump when my Time Machine backup started in the background in another (discarded) occurrence.

      B: with DDS: 183.68 +/- 1.96 ms per iteration. Still a lot of fluctuations (plus a drop after around 200 iterations for whatever reason):

For kicks, I enabled the disabled diagram and the results are as follows:

185.47 +/- 2.32 ms per iteration. Fluctuations as always:

On the face of these resuts, there appears to be an effect of putting something in a DDS WHEN USING DEBUG MODE ON.

[AristosQueue (NI)]

> On the face of these resuts, there appears to be an effect of putting something in a DDS WHEN USING DEBUG MODE ON.

Yes! As I said earlier in the other thread, yes, this is expected behavior. If you have a structure node with no internal structures, you have a different clump behavior than if you have a structure that contains other structure nodes. ANY other structure node will shift things. There is debug code for those structures when debugging is one. That code, and those structures, maybe be removed by compiler transforms when debugging is turned off.

You didn't have to go to the effort of proving this.  But thank you... it's useful to have a post to point at to show just how noisy profiling is without a dedicated testing arena with stripped down machines (ie. no Time Machine).

[MGiacomet]

AristosQueue, you are missing the point.... While I agree that using your proposed (yet cumbersome) workaround of disabling debugging eliminates the overhead, it doesn't justify that adding a Diagram Disable with NO CODE in the Enabled state adds to the execution time. In ANY language (well, except LabVIEW), disabling (source) code does NOT add overhead. Take, for example C/C++: When you wrap code with the pair of preprocessor directives #if/#endif, the code inside them is disabled and it does NOT add overhead. The expectation is that when disabling code, in this case using the mechanism available in LV, i.e., Diagram Disable, the code would not execute and would actually reduce execution time. I would encourage you to enlighten yourself by reading the link provided by jcarmody https://en.wikipedia.org/wiki/Principle_of_least_astonishment Also, you are applying circular reasoning by stating: "If you truly believe you have a bug, please go through an AE so you can talk them through steps to replicate." If I were to do that, they'd say that's "expected" behavior and to post as an Idea. Furthermore, assuming the valid "explanation" is because debugging is enabled, tell me, what good does the code in the Disabled state of the Diagram Disable do? How do you debug that??? If your answer is "can't be debugged", then you get my point.

[X.]

I think your suggestion should be about adding a layer of intelligence in the handling of DDS in debug mode. A lot of DDS have an enabled case that DOES something, be it only pass data through untouched. This needs to be handled during debugging, hence the overhead. Your use of the DDS to isolate an unused piece of code is legit, but not universal.

[AristosQueue (NI)]

> it doesn't justify that adding a Diagram Disable with NO CODE in the Enabled state adds to the execution time

You still have enabled code even with an empty frame. What is that enabled code? The enabled code is the execution highlighting markers. You added a structure node that forces a loop to have new clumping logic. Any structrue does this, not just the diagram disable structure. An inner structure injects new debug nodes into the code in order to update execution highlighting correctly -- and execution highlighting still has to update even for a diagram disable structrue. That injection changes the clumping rules for the loop overall.

This is simply the way things work -- if we are going to provide debugging, then we have to include the code that lets us do debugging. Even if that is astonishing to  customers.