LabVIEW
LabVIEW 2026Q1 super slow launch
@Andrey_Dmitriev wrote:
Yes, I see the same issue from time to time in a corporate environment, including with previous versions. Also, right-click popup menus sometimes take 3-5 seconds to appear.
At a customers external production site even opening Explorer can take 20-30s the 1st time after boot. I assume it was looking for some policy or AV in a non-existing network.
I tried poking around to see what function calls are slowing it down, but couldn't find a smoking gun in the time I was able to mess with it.
LabVIEW does need to look at a LOT of files, so I'm guessing Windows Defender doing a check on each and every one could slow it down. Scroll down to the "Find the folder or app that defender keeps scanning" section of this article: https://blog.gridinsoft.com/antimalware-service-executable-high-cpu-memory-fix/
See if you can capture the slow startup using the MpPerformanceRecording tool. The last time I tried it, LabVIEW opened in like 10 seconds so I couldn't capture it 😄
@ConnerP wrote:
If you are using VIPM packages, which I would suppose you are, try wiping them and see how LV behaves. If it is better, add them back slowly. Last year QControls made my system absolutely unusable. I presume it had more to do with enterprise virus scanning than QControls itself, but once I de-installed that, things were back to normal.
That's not a solution i you use them though. 🙂
@ConnerP wrote:
If you are using VIPM packages, which I would suppose you are, try wiping them and see how LV behaves. If it is better, add them back slowly. Last year QControls made my system absolutely unusable. I presume it had more to do with enterprise virus scanning than QControls itself, but once I de-installed that, things were back to normal.
It is not only VIPM...
Actually, I stopped doing this kind of investigation with Process Monitor after the introduction of Quick Drop, since it walks through all palettes and files in `vi.lib`, and so on. I even tried to "fix" it by creating my own Quick Drop variant because of that annoying message, which is still present in recent LabVIEW versions:
To be honest, I don't understand the logic. What's the problem with populating that list once, saving an indexed list of entries somewhere, and then rebuilding it only when necessary, for example after installing new toolkits, after a VIPM package installation, or on explicit user request if I manually add something to `user.lib`?
But no. If I start LabVIEW and immediately hit *Ctrl+Space* to wire up my latest genius idea, I'm greeted by that message instead... and by the time it finishes, I've often forgotten what I wanted to drop in the first place...
Back to long startup story; for example, Visual Studio seems to make startup and performance improvements with almost every release and has become blazingly fast:
RustRover automatically excludes heavyweight build directories from Microsoft Defender scans. In a corporate environment, I can't adjust Defender settings myself, but approved software can do it, and that significantly improves build times. This is what software looks like when developers actually think about other developers in mind:
Anyway, let's do one more round on my PC. As usual, I started LabVIEW today morning and went for a coffee break, but this time with Process Monitor running. I configured it to capture only file access activity, excluding registry events.
When I came back, this is what I found:
The entire startup process until LabVIEW finally "stabilizes" takes slightly over seven minutes. Long enough to drink an espresso, maybe even a doppio.
In total, there were 2,227,362 entries. Two million two hundred twenty-seven thousand three hundred sixty-two. Not every entry is single read/write I/O, multiple can be logged for single action, but anyway — over two millions are here.
However, there are not over two million unique locations. The number of unique paths and files is only 204,508. That means each location was accessed (logged), on average, about 10 times. It looks as though several NI components contain loops that repeatedly walk through files and directories, possibly from multiple threads. Often happened when multiple teams working on same software without proper organization.
Lets continue, not every file or location that LabVIEW tries to access actually exists:
- 626,849 `PATH NOT FOUND`
- 65,923 `NAME NOT FOUND`
The number of failed accesses exceeds the number of unique paths because LabVIEW repeatedly attempts to access the same non-existent locations. Apparently, it is not enough to determine once that Digital Filter Design is not installed on my PC. The same locations or same file at different locations are touched again and again and again, just to make 100% sure - its not here:
The most frequently accessed champion file is lv.emf:
C:\Users\XXXXXXXXX\AppData\Local\Temp\lv.emf108,114 times
1. 108,114 \AppData\Local\Temp\lv.emf
2. 57,141 \LabVIEW 2026\VIObjCache\26.0.0r0\objFileDB.vidb
3. 30,385 \Documents\LabVIEW Data\VIObjCache\26.0.0r0\objFileDB.vidb
4. 21,995 \NI\LVAddons\nidaqmx\1\vi.lib\DAQmx\calibration\calibrationInfo.llb
5. 21,640 \AppData\Local\TempNot sure why DAQmx calibrationInfo.llb is so special, but anyway.
19 seconds:
Top 5 (same event):
Operation: NotifyChangeDirectory: AppData\Local\National Instruments\UserAccount
1. Duration = 18.7400006 sec Time = 07:48:04,6357278
2. Duration = 6.2637547 sec Time = 07:47:51,8467882
3. Duration = 5.2753364 sec Time = 07:47:58,4425590
4. Duration = 4.4864593 sec Time = 07:47:31,8993870
5. Duration = 4.3807212 sec Time = 07:47:40,4087642
However, these appear to be non-blocking delays. The next operation usually follows almost immediately. My guess is that these are simply notification waits, and the same pattern appears multiple times throughout the log.
Still, 2,227,362 file access events in seven minutes means an average of 5,229 events per second. That's quite aggressive polling of my SSD for a startup sequence and seems a little excessive...
What a disaster. 😄
The only positive aspect is that I usually have the kind of PCs that "best money can buy", thanks to my employer. I can only imagine what the experience is like on a slower machines.
I've attached a trivial AI-generated Rust analyzer. To build it, you'll need Rust installed. Feel free to modify as you need, then simply build with:
cargo build --releaseand execute the binary (from target\release folder) against your ProcMon CSV exported file with enabled Duration and Relative Time Columns.
Enjoy and have a nice weekend!
@1984 wrote:
Did not spend too much time on the process analyzer yet, but during the one test I made I've seen that
\AppData\Local\Temp\lv.emf
took half of my boot time. Thousands of activities was related to that single file while labview was starting up.
.emf is a picture format, and my lv.emf is this ...
How many times would one need to load an icon?
