Slow Compile Times After the First Compile

[WillStad]

Hello Everyone,

This is my first time posting a topic. I have a medium/large sized application that I have been developing and supporting for a couple years now and I am experiencing very long compile times of almost 3 minutes per compile for the last few weeks.

The strange thing is when I first start my computer and compile, it's quite fast with a compile time of about 30 seconds which is what I would expect and what I have been used to with this program. After that every compile is almost 3 minutes or greater which is really slowing me down. 

I've worked with the IT department to help isolate the problem and we did things like disable the virus scan and monitor the processes to see what could cause the issue. But we haven't found the issue. We did some maintenance on the hard drive such as disk fragmentation and scan disk. I even completely uninstalled CVI Lab windows and reinstalled to CVI 2017 and the issue still exist.

I am compiling locally on a SD drive. I've tried many of the compiler settings to increase compile times and in fact if I turn some of the optimizations off it takes upward of 5 minutes to compile. That being said if I restart my computer the first time I compile it's fast again. I'm always adding or changing this to this application, but there hasn't been any major component or library added to this program since I've encountered this issue. Plus, the fact that it compiles quickly the first time leads me to believe that my program should be alright.

Does anyone have any thoughts on what could be happening here? 

I've included a screen shot of my build settings and the problem persists in both debug and release mode.

[Gaus]

Hi,

For CVI2015 I've observed very long linking time if the Application Icon File was not selected. The linking time varied from one second to half a minute. Maybe others have observed this. If this problem is related to your problem is uncertain.

[WillStad]

Hello Gaus,

Thanks for your input. I was noticing this issue on CVI2015 before I decided to go to CVI2017 to troubleshoot this issue. I tried your suggestion and played around with the icon files. I'n not seeing an issue here and I've included a snap shot of my Target Build settings. I tried using another Icon file and I get the same effect. All my Icons are stored locally in my project folder.

You bring up a good point. I have been using the catch phrase "compile" for my issue but I highly suspect the problem is in the linker. In fact a simple compile on a source file runs quickly. When CVI is stuck building my project for 2-3 minutes there isn't much CPU overhead and windows flags CVI.exe as an unresponsive program.  

[Vondree]

Hello,

I don't know if you are still having issues but I had the same problems on my system, but here is how I solved it:

I am working on an NI embedded controller with only 2GB ram so I first turned off "advanced debugging features" that were trying to use more memory because from other things I read on the internet, it seems to be a CVI reoccurring issue (especially with large static arrays in which I have some).

Even with these features disabled, I was still having slow "compile and linking" times after the first one or computer restart. I found that if I ran the Clean function (Build -> Clean) after each debugging session I was able to get the fast compiles every time.

Instead of trying to remember to hit the Clean button every time (since it was about a 6-10 minute wait if I forgot) I added some post-build actions in the Build Steps (Build -> Build Steps) to delete all files. For me it looked like this:

del /F /Q cvibuild.project\Debug\File1.bat

del /F /Q cvibuild.project\Debug\File2.txt

and so on...

Let me know if you have any other questions.

[Razvan_P]

Hello WillStad,

looking at your target setting print screen, I noticed that you're embedding user interface files into the executable. You may want to do a test with that checkbox disabled to see if you get some improvements.

For a more precise diagnose you can try to enable build logging for build by launching ConfigureCVILogging.exe from National Instruments\CVI2017\bin folder. After launching the tool you may want to enable logging for CVI 2017 Environment and redirect the output to a file.

The you can start CVI, perform a build then close CVI and look at the log file to determine which step took longer than expected.

Hope this helps. 

[WillStad]

Hello Razan_Pora,

I've been working with your suggestions this morning and trying out some things that Vondree mentions too. I'm not noticing any difference in compile/link time when I deselect the embed .uir file in to executables. It was a good suggestion, I have 4 .uir files in my project and I imagine most GUI's have only one. I get the same result with release mode.

However, I might be on to something with the build ConfigureCVILogging tool you recommended. I made three logs, one where the log took 30 seconds, another that took about two minutes, and a third that took about 2 minutes and 48 seconds. Firstly, for some reason the majority of the log files are empty space until the the end of the file where it looks like the logging begins. I am not sure if this is normal. It happens on all 3 files. The hang up appears after the first two logging lines by looking at the time stamp. Here is the snap shot of the text:

30 second:  (Time between logs = 26 s)

[09:47:24.601] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag
[09:47:50.863] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag

2 Minute: (Time between logs = 2 min 2 s)

[09:40:36.860] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag
[09:42:38.342] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag

2 Minute 48 Seconds: (Time between logs = 2 min 2 s)

[10:01:15.616] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag
[10:03:17.558] [INFO] [GetUniqueTag] [..\james\ui_tree.c:608] Search 0 times to get a unique tag

You can see that the exact same process takes two different times. After this hang up, the rest of the build takes about the same time with the same steps. I've included the logging files if anyone wants to take a look.

I have no idea what the compiler would be doing during this time since it doesn't log it nor do I know what action the compiler is doing at this time. 

Any thoughts?

[WillStad]

Hello Vondree,

Thanks for your suggestions! I am still struggling with this issue and I've sort of lived with it for the moment. It's good to know I'm not the only one who has experienced this issue. 

I haven't been able to disable the "advanced debugging features" I'm not sure how to do that. I also use static arrays of various types in my functions. I'm willing to try anything at this point. However, the issue persists when in release mode too which leads me to believe it's not in the debugger, but I don't know for sure. 

Cleaning the build is amazing and it has solved some troubling problems I had in the past, but it has no effect to for my compile time unfortunately. 

[Vondree]

Just so I understand, running a Clean command before compiling does nothing to improve the speed?

When I read through your first posts, your situation seemed almost identical to mine. I also had seen the long compile times after the first one in both CVI 2015 and then when I went to 2017 it temporarily went away. It seemed to return after I added more to the program (which added to the program's total memory size). I ended up struggling with this issue on and off for about a whole week uninstalling and reinstalling CVI programs / registry values. The embedded system I am using has barely any company security software on it since it pretty much stays off the network so I knew it wasn't any other background software affecting it.

I don't know too much about the compilers and logs it produces but I figured it must be trying to reuse intermediary files to try to be even faster next compile and ends up getting confused instead. So by deleting the debug files it forces the compiler to start from scratch again (a known state).

Make sure that the clean function is actually doing its job and files are removed. I've also had the issue of the Clean command failing if I interrupt/cancel the long compile process mid-way (it locks the files in Windows).

[WillStad]

Hello Vondree,

Yes that is correct. The clean doesn't reduce the compile linking time. I just did another test after reading your reply to make sure. I have been using google stop watch to measure these times. So I timed a normal build with a time of 3:30 before the clean, then did the clean and verified that the debug folder was deleted. I re-compiled and got a compile time of about 3:51 surprisingly. I almost always let the compiler finish and close my program normally through my close and quit functions. 

Also it's still true that it compiles faster when I restart windows for one time. It's almost faster to restart my computer then it is to build again honestly. 

[Vondree · Accepted solution]

Hello,

My solution is still working well for me but I did think of one more thing you could try to get faster compile times. Back when I was having issues, CVI would occasionally crash during both compile times and during some executable startups. Whenever I reopened the program it would take a good 5-10 minutes to show the splash screen vs (on a good launch: 20 seconds). To fix this, I reinstalled/repaired the CVI program through the Add or Remove Programs window. After the tool went in and auto corrected all the registry values and other settings, crashes would stop happening for a while and loading times decreased significantly...until I broke my modified my program again (but that was on my end.

I suggest that if your CVI has ever crashed at  any-point in the debug process (or even if it hasn't), run the repair tool. It can be found at:

Add or Remove Programs (in the control panel)

National Instruments Software --> Uninstall/Change

(type in Adminstrator Credentials)

Highlight the NI LabWindows/CVI 2017 item

Press Repair

On the Select Distribution Popup Press OK

Hope this helps if you were still having issues.