Slow Compile Times After the First Compile

[WillStad]

Hello Vondree,

What you suggest is a great tool. I didn't realize I could repair software installs from Windows Add/Remove programs. This is for sure a powerful troubleshooting step. Thank you for suggesting this. 

I did exactly what you said and repaired the CVI lab windows 2017 install. The repair took some time to do also.

Unfortunately, I am experiencing the same compile time behavior with greater then 2 minute compile times and it always compiles quickly on the first compile when I restart my computer. I also did a few build cleans. I'm not seeing any change as I mentioned before I have been using google stopwatch to measure the build times. Unfortunately, I don't have much choice as I sort of have to live with it since I have more development that needs to be done.

However, there is a silver lining, since I have to wait so long between builds I have been writing better code on the first try and I don't rely on the compiler so much to flag down errors. Also, during debug I really analysis everything that is happening before I quit a run and recompile. In a way I'm a bit sharper. In addition the IT department at my company is trying top get me a faster computer since they can't seem to help with this issue either. So there is plus side. Honestly, I suspect there is some kind of network protection or process running in the back ground that slows CVI down. After the first compile, this process might flag CVI as suspicious and monitor it heavily during subsequent complies. I really kinda at a loss here but there is only me and another person at my company that writes code.

But I really appreciate your help. Thank you for your suggestion. 

[WillStad · Accepted solution]

Hello Everyone Who Helped me with this issue. I am happy to report that I solved the problem!

This issue has plagued me for months, until recently my compile times were taking almost 20 minutes per build instead of the original 3 minutes. And the issue was.... drum roll please..... a corrupt CVI project .prj file! 

After running my CVI project on several different computers, settings,  Windows 7 to 10, and in safe mode I realized the super sluggish compile times were coming from my project. I simply saved my project under a new name which just gives me another .prj file. (All my other .c and .h files are the same with the new .prj file.) I had to clean up a couple header files in my project to get it to compile which I found interesting, but after that it works every time. Average compile time is less then 10 seconds now! 

I wanted to finish this post even though it is several months old in case there is someone else with a similar problem. Thank you for everyone's support. 

[LuisG]

I don't suppose you still have the old project file, do you? Or the differences between the two files? It would be interesting to know what about it, exactly, might have been causing this problem.

[WillStad]

I still have a copy the old .prj file if you want to have a look. M-Light.txt is the corrupt file, M-Light_Rev2.txt is the working file. I had to change the file extensions from .prj to .txt to upload them to the forum. Just re-name them back and I think they would be fine. I would be interested to know why the file is corrupted. I have been using the M-Light.prj project file with this application for several years.

[LuisG]

Sorry for the long delay, I've been away from the forum for a while.

I compared those two project files, and unfortunately, nothing obvious jumps out that would account for those build time differences. There is nothing apparently wrong with M-Light.txt, so I wouldn't really call it corrupt.

I don't doubt the results of your experiments, but it's possible that the change in the project file might have been only indirectly responsible for eliminating whatever it was that was causing that slowdown. For example, given that some paths are different in the two project files, it's possible that during compilation the standard file search that the compiler does to find header files might result in the inclusion of different header files (with the same name), because of the different relative paths. These alternate header files could have had something in them that could conceivably have resulted in different build times -- although it's not easy to imagine what make such a large difference (network path timeouts, perhaps?)

There could be other side effects of the path changes that could account for this, but I can't think of any specific possibilities right now.

Also, it sounds like this wasn't just a simple binary outcome. You said that you started off with a 3 minute build, which suddenly jumped to 20 minutes and now, with the new project file, is down to 10 seconds. That's a pretty big difference not just between the first two times but between the current time and the original time.

Luis

[dadapolaris]

Hi Willstad,

 I have the same issue and I just solved it by saving.prj as a new file as you suggested!

Thank you so much!

[VinStorm]

Hi Willstad,

I had the same issue, solved as you suggested by saving.prj as a new.prj.

you saved me a lot of time 🙂 🙂

many thanks!!