Why does my code run faster in development mode then when compiled?

[tronchaser]

My co-worker and I recently discovered a race condition that didn't pop it's ugly head until our program was run on very fast Xeon machine, it turns out that a parallel thread had a timing loop that allowed this condition. No problem, easy fix. We then started to benchmark our machines to see just how much faster the dual Xeon CPU machine ran compiled labview code. I wrote a small program that was simply a while loop with an external mSec timer and an internal mSec timer so that the external gets subtracted from the inner. I use a conditional greater-than 1000mSec to stop the loop. I display the "i" iteration count to see how many times the loop ran. Here are the results, much the opposite to what I would expect:

Development mode on my 600Mhz laptop: 2.0E6 iters per second
Compiled to EXE on my 600Mhz laptop: 234.4E3 iters per second
Compiled to EXE on the dual Xeon CPU machine: 1.2E6 iters per second

Why would it run 8 times faster in development mode??

Very odd...


The program is attached if you would like to try it for yourself, it is very small.

[altenbach]

Interesting, I see the same thing...

1.8GHz Athlon XP 2500 (Barton) under LabVIEW 7.1.

Dev: 6.6E6
Built: 1.1E6

Strange .....

[chilly_charly]

That's something PC specific : doesn't show up on my Powerbook.

CC

[tronchaser]

---

@chilly charly wrote:
That's something PC specific : doesn't show up on my Powerbook.

CC

---

CC:

I ran it on three different target PC's...

1. Dual Xeon CPU ($10,000 computer)
2. Dell 600Mhz Inspiron 6000 Laptop
3. Home PC 1.4 Ghz 768Mb Ram

All three exhibit the same phenomenon...

Your machine ran same speed in development mode as it did after compiling to EXE?

[GerdW]

Hello tronchaser,

on my machine (Win2k English, LabView 7.1 English, Athlon 2500+, 512MB) it is the same:
development version6.5e6
compiled exe

[GerdW]

Hello tronchaser,

on my machine (Win2k English, LabView 7.1 English, Athlon 2500+, 512MB) it is the same:
development version 6.5e6
compiled exe only 1e6

Maybe NI can explain this...

Best regards,
GerdW

[chilly_charly]

Hi Trochaser !

Sorry, I forgot to mention that a Powerbook is a MacOS machine.
I should have written "That's something WINDOW specific : doesn't show up on my Powerbook."

CC

[altenbach]

I suspect this difference is very specific in this particular case. An otherwise empty loop brings out the difference.

I have many built applications that do hardcore computations and the code typically includes timing information. In all these cases I see absolutely no difference between development and runtime environment.

I have added a shift register to your example, inverting a small array (128 elements) with each iteration and the speed of the built application now is already within 75% of the development environment.

I would love to hear an explanation by NI. 🙂 This should still be fixed.

[altenbach]

If you can live with a few less significant digits in the precision of the result, use the attached code. Here the built application is initially 20% faster (As expected due to automatic removal of debugging code. If you disable debugging in the development environment, the results are within a few %).

This clearly shows that the only culprit is the "tick count" and not some inherent difference in empty loop speed in the two environments. It also tells us that "tick count" is a relatively expensive function, contributing largely to the loop rate in your example.

[THailey3]

Hi Tronchaser!

You beat me to the punch, Altenbach! It does seem to be an issue with the TickCount(ms).vi. I actually verified this with a different VI that just counted as fast as it could for X amount of time. When you run the VI in LabVIEW (and disable debugging) and its EXE, there is no significant difference in the amount of iterations completed (sometimes one is a little faster than the other, but with no consistency).

This is very peculiar behavior and probably attributed to how the TickCount(ms).vi executes with the given operating system. According to CC, this behavior is not prevalent on a Mac. However, in Windows, there is an obvious difference in speed.

I have alerted R&D on the issue!

Thanks for the feedback and hopefully this will not be an issue in the future!

Travis H.
Applications Engineer
National Instruments