Big Performance Degradation in LabVIEW 2012

[Ben]

There are at least two diff's between 2011 and 2012.

1) THe bug that prevented probes on RT nodes from updating appears to have been fixed.

2) I believe the "Distributed System Manager" seems to be new.

We can not un-do the bug fix for the probes but it is possible to Add/Remove the "Distributed System Manager".

Have you tried that yet?

Re: the validity of the test in question

It test not only yhe efficiency of the code but also the environment the code is running in and gives a relative number that tells us how much can be done in a given period of time. Very valid for RT applications in my mind eye.

Ben

[User002]

The "Distributed System Manager" has been around for a while.

The performance issues are present on Windows as well. It's not a RT issue alone.

Br,

/Roger

[David-A · Accepted solution]

Hi Roger,

Some testing appears to have narrowed the slow down to dynamic dispatch calls since:

•  The ExecutionBase.lvclass:update.vi called from lock.vi runs more than twice as fast in LabVIEW 2011 as in LabVIEW 2012
•  Changing the call to static dispatch improves performance with both 2011 and 2012 (roughly) equivalent

From the above, it's suggests to me that the issue is a performance issue with specific instances of a dynamically dispatched VI.

Disabling the block diagrams for each Update VI's (Parent and both children), shows that the slowdown is related to the overhead.

I made a trivial test VI that demonstrates this as well.

What is important to keep in perspective is that the additional overhead associated with a dynamically dispatched VI is on the order of 2 microseconds greater than it was in LabVIEW 2011.  So even though it is demonstratbly slower it is negligible in all but the most extreme cases.  Regardless, I've gone ahead and filed CAR #372784 on this issue.

Regards,

David A

[User002]

What is important to keep in perspective is that the additional overhead associated with a dynamically dispatched VI is on the order of 2 microseconds greater than it was in LabVIEW 2011.  So even though it is demonstratbly slower it is negligible in all but the most extreme cases.  Regardless, I've gone ahead and filed CAR #372784 on this issue.

Regards,

David A

---

No, it is not negligble in any case. Overridden dynamic dispatch methods in tight loops would be severly affected by this performance bug as I clearly have demonstrated with my benchmark code.

Talking about relative terms such as '2 microseconds greater', than what? '1 nanosecond'?.

Trying your hardest to motivate why your 31337 C++ |-|@><0r doods @NI kinda' didnt botched the OOP performance in LV2012?

Anyway, thanks for showing interest in improving LV2012 with the CAR.

Br,

/Roger

[BradyDuggan]

Just wanted to give an update from our initial investigation into this CAR in LabVIEW R&D. We have reproduced the issue in our performance test grid using the paired down test VI that David A posted. We're seeing a 30% slowdown in loop iteration speed using that test between LV 2011 and LV 2012. Digging in further, we've narrowed it down to a change introduced during development between LV 12.0d117 and 12.0d130. We will continue to work to pinpoint what caused the performance degradation and to remove it if possible.

Thank you Roger for bringing this to our attention and working with us to reproduce the issue. I understand that even small changes in execution performance can manifest into large impact in things like tight loops. While we do put forth significant effort to monitor, maintain, and improve runtime performance each LV release, some times degradations slip through the cracks. However to help ensure this particular issue doesn't happen again, this performance test will be added to our regression test suite and monitored against future LV releases.

Thanks again for all your effort in identifying this issue. I'll continue to update this thread on our progress with the CAR.

Brady Duggan

LabVIEW R&D

[maxwellb]

Has any progress been made on this CAR? Was anything changed for 2013 or 2012 SP1?

[mfletcher]

I manage the LabVIEW R&D team that monitors performance and addresses degradations in addition to owning other features. No changes were made in LabVIEW 2012 SP1 or LabVIEW 2013 to address this degradation. CAR 372784 has been on our radar, and we understand it is a painful degradation.

Mary Fletcher

LabVIEW R&D

[maxwellb]

Thanks for the update!

https://decibel.ni.com/content/thread/19028

I see some signs that dynamic dispatch is slightly slower in 2013 than 2012. Results posted in the comments there by komorbela. Has this been tested by R&D and do you agree?

[Intaris]

I just want to chime in and say that I'm still of the opinion that the DD performance in LV 2011 (although clearly better than in LV 2012 or later) is not the final resting spot we should be looking for.

I've yet to hear why, internally, a DD call requires so much more time than a standard VI call encased in a case structure (i.e. a mock-up of DD).

[mfletcher]

Yes. Our test shows that an empty dynamic dispatch call in LV 2013 is 4% slower than LV 2012.