Built EXE is ~100x slower until the original source code is ran in IDE?

[m3chtroid]

So I have a large, LVOOP, interconnected application.  I build the application into an executable, and everything works fine.  Opening and parsing a collection of json files takes approx 117ms, all the profiling works fine.  Then I start distributing this executable to other users, and opening and parsing the *same* collection of json files takes upwards of 9.18 seconds?  So I have one of my coworkers download and open up the project file and try to run the application in the IDE to debug it.  Oddly enough, the version ran in LV2019 loads everything in around 100ms, so the problem isn't reproducable.  But here's where it gets weird:

At first, the built executable took ~10 seconds on my coworker's machine.

After downloading the source project, that version runs in a tenth of a second.

And now, the original, unmodified, built executable runs in 121ms!

My coworker then deletes the entirety of the source project, thinking the executable was using vis from the source instead of the build.

The original executable still runs in 121ms!

How could running a program in the Labview IDE suddenly make a built executable speed up by a factor of 100?  Aren't built applications entirely using their own compiled code, what could have changed to speed up what's supposed to be a self-contained application?

[LLindenbauer]

My first instinct would be file system issues. Network drives, Antivirus Software, auto-mounting, raid arrays, hybrid ssds, ram drives, caching etc. will cause huge variations in execution performance, especially when your net computing time is in the range of a fraction of a second.

If You want to measure computing performance, separate the IO part from the computing part. If your code only takes a fraction of a second, it might even be stalled by the operating system doing something else right at the moment, like downloading patches, emails, autosaving the spreadsheet You just edited ...

If You want to analyze the issue, increase the problem size so that it takes at least a few tens of seconds to solve. Generate the data in memory before and do not read from disk. You might need to do some tricks to prevent to compiler from just skipping the computation. I think there are also some tools for code profiling in LabVIEW You could take a look at.

[m3chtroid]

That's the thing, I've done it multiple times, and it matched down to the tens of miliseconds.  

Here's the procedure I tested on multiple machines and multiple users:

• Download the build artifact (An executable that only required the labview runtime engine to run)
• It would always take the built executable ~9,200 milliseconds to parse the same test file.
• Download and install Labview 2019 SP1 on the machine if it doesn't already exist.
• Built executable still takes ~9,200 ms to parse the test file. --This rules out the mere presence of the development environment itself as the source of the speedup.
• Download the source project from repository, load it up, run the program in the Labview Development Enviroment.  
• This version, not the executable, but a vi ran from source takes 112ms to load test file.
• Close labview and delete the entirety of the source project. -- this rules out the presence of the source files affecting the performance of the build artifact.
• Run built executable downloaded at the start of the procedure.  Parsing the test file is now 9,000% faster, taking 112ms.
• Rebooting, downloading a new version of the build executable, no matter what, I cannot get the program to take 9 seconds to load the test file anymore.

This is a noticeable and reproducible speedup of around *one hundred times* faster gained simply from loading up the original source code in Labview and running it.  I appreciate the advice, but I fail to understand how file system issues would persist across multiple machines, cause slowdowns of this magnitude, and then disappear forever after a single action.

[Kyle97330]

A few questions:

When you say that you tested it on multiple machines and users, do you mean different users on the same machine?  Specifically, if user X runs the program in LabVIEW, does it speed up the EXE if user Y is logged in later without having run the program in LabVIEW?  If it only applies to one user, does deleting "C:\Users\<user login name>\Documents\LabVIEW Data" revert back to the slow speed for that one user?

If you delete or rename "C:\ProgramData\National Instruments" on the machine after it speeds up, does it slow down again?

(Note:  I'm not totally sure that deleting all those files will still let the RTE work, I just know that the development environment, NI-MAX, and so on uses it)

What about uninstalling LabVIEW 2019 while leaving the RTE, or just renaming "C:\Program Files (x86)\National Instruments\LabVIEW 2019" to something else temporarily?

Could you make a new version of the EXE where you record and save timestamps of the execution of every node to see which node or node the slowdown is in specifically?  If the slowdown can be isolated to either the filesystem or the JSON decoding or somewhere else, that might narrow down the issue.  It would also indicate if it's a minor slowdown every iteration of a loop or if it's one major slowdown at the start or end of the whole thing.

[crossrulz]

You might be able to use the Desktop Execution Trace Tool to see if you can do some debug.  It might help figure out the slow downs.  It has been a long time since I played with it, so I don't remember what all it can find for you.

[Yamaeda]

Strange indeed. The only thing i can Think of is if the exe somehow is missing of misplacing some files that it needs searching for or if the fact that you opens the program recompiles stuff and you're somehow using this object cache. Most peculiar.

[m3chtroid · Accepted solution]

I timed the nodes to drill down what was taking so much time, I assumed it was dynamic dispatch, but it wasn't.  In a property setter VI, I validated the IP address string by converting the string to ip and back, then comparing.  For some reason I don't understand, every time I hit this VI in the built EXE it takes 5(!) seconds to run, while next to no time after the dev environment is ran.  Since there were two objects with this property in the JSON I was parsing, it increased loads to exactly 10 seconds and change.  Strange behavior indeed.

(To clarify, the code wasn't disabled when the bug occurred, I just did this to fix it as well as I could while in progress.)

[Kyle97330]

Looks like you might have hit the same issue as this thread (I remembered it because I posted in it way back when).  Even though the circumstances are different, the timing is the same (4.5 to 5 sec) and the solution is related (installing a version of LabVIEW).

[rolfk · Accepted solution]

The IP to String node with false input does a DNS name lookup through Winsock and the function in there has a fixed 5 second timeout when the DNS request doesn’t get answered.

There is nothing LabVIEW could do to use a different timeout (the Winsock function has no parameter for that) and the function returns with an error in which case LabVIEW falls back to converting the IP address to a dot notation string.

Why installing the LabVIEW IDE suddenly would make the DNS query succeed is a riddle to me however.

[m3chtroid]

I tinkered with it some more and I have a suspicion it has to do with IT's firewall rules, as labview.exe is allowed unconditionally.  Building the exe to the same name fixed the problem as well, but I'm still unsure why running it in the dev environment fixes the built exe with a name blocked by the firewall.  I suspect it has something to do with caching on windows' side of the equation.