Compilation in CVI2013

[Wolfgang]

Hello,

I am still discovering all those nice features of CVI2013, so here I am with two questions on compilation:

1) On the Build Options / Configuration Options panel, the checkbox 'Show warning flags in Build Output window' does not seem to have an effect: in both cases I do get the warning messages (Warning level set to Custom). So what is a warning flag?

2) The announcement of the top new features of CVI2013 claims faster build times. My impression is that now, using CVI2013 in debug mode, the same code takes about 5 times as long to compile. Unfortunately I did not measure the compilation time before upgrading, so it is a rough guess only... Is there a setting I may have overlooked?

Thank you!

[LuisG]

Hi Wolfgang,

That option doesn't determine whether you see a given warning or not. To enable/disable warnings you have to go inside the Compiler Warnings dialog box.

The warning flags are IDs for each individual warning, and this option allows you to more easily connect a specific warning that you see in the Build Output window with the warnings in the Compiler Warnings dialog box:

As far as your compile times is concerned, it's definitely unexpected that it would take you 5 times longer to compile. Are we talking about the simple compile time of a given file, or the full build time of the project? Also, do you remember whether when you were using the CVI 2013 beta you had already noticed it with this project?

Luis

[Wolfgang]

Hi Luis,

Thanks for your reply, as always!

1) Thanks, I do see the difference now

2) Yes, I am talking about a simple compile (debug 32 bit) and build using the green triangle button. I do see the difference on two different computers with different OS (XP vs. Win7) and quite different hardware. For the beta, I used my old notebook so I can not tell if there is a difference... If you think that it may help you I can compile using the beta, take the time, and then install CVI2013 on the notebook, too... 

[LuisG]

Hi Wolfgang,

No you don't have to go try the beta again. I was just curious to know whether it might have been something that had changed since the beta. But that's not that important, anyway. What would help would be for us to try to reproduce it. If you happen to have some file that is slower to compile in 2013 than 2012, and if we could compile over here, that would help. Do you think you could send me something like that, even if it via private message or the ftp site?

Luis

[Wolfgang]

OK, I have sent you a PM... Thanks!

[LuisG · Accepted solution]

Hi Wolfgang,

Thanks for the project. I did confirm that it takes, as you said, about 5 times as long to compile with CVI 2013. I don't have an explanation for you at this time, but I've created a bug report (#422103) to investigate it soon.

Luis

[Wolfgang]

Thanks, I am relieved that you could reproduce it!

[LuisG]

Hi Wolfgang,

I have some preliminary results of this investigation to share with you.

In general, debug build times are faster in 2013, as our internal benchmarks have been showing, primarily because the linker is faster, and multi-file projects can take advantage of concurrent compiles (Options>>Build Options>>Build Process Options>>Number of concurrent compiles). Also, all things being equal, full rebuilds of projects with precompiled headers are faster in 2013, since the time it takes to generate the precompiled header in 2013 seems to be noticeably shorter. Our internal benchmarks use a mix of different projects and there are enough projects in that mix with precompiled headers and with a large enough number of source files in them that their average build times are faster in 2013.

Unfortunately, the pure compilation time of a single file seems to be consistently slower in 2013. In your case, your single file is sufficiently large (it's really quite large) that it overwhelms the faster link time. And because it's a single file, it also does not benefit from the concurrent compiles option.

This issue is still open, but I wanted to give you an update of what I know so far, in case you're at the point where you'd consider splitting up your file into several files, in case this becomes too annoying. 

Luis

[Wolfgang]

Thank you for the update.

This also addresses a question I had in mind concerning the optimum number of cpu cores to specify. I know several programs where the shortest times are achieved for an intermediate number of say 3 cores due to the added overhead to split computation. As I understand, recompiling a project where only one file has changed (this I would consider my standard case even if the project consists of 30 source code files) will not benefit from a multicore computer, right?

[LuisG]

That's right. Compiling just a single file would not benefit from multiple cores. But that does not mean that you have to be changing the option back and forth between 1 and the default value. It's okay to always leave it set to the default value. If you are compiling just a single file, it will only use 1 core anyway, regardless of the value of this option.