slooooow linking

[wilcomir]

Hi everybody!

I've installed codeblocks on my desktop pc, and it works well, but on my laptop it's tooo slow: I mean, compiling is of course very very fast, but linkin 10 lines (yes, it's 10) takes my pc 1:20, 80 seconds. I really can't understand the motivation, I've searched around and I've found something about the "number of processes for parallel building" option, located in "compiler and debugger settings" "other settings". I've set it to 3, as my laptop is a dual core, with no effect.
my laptop's got an intel core 2 DUO and 3Gb of ram, i use windows xp pro sp3, and the GNU compiler. all the codeblocks settings are the default ones, except the one I mentioned. I've also already tried to uninstall and install codeblocks, but it's still the same.

thank to everyone who will answer me!

Ciao
Vladimir

PS sorry about my english, but I'm Italian

[koso]

Have you tried to link it without C::B => usign direct compiler/linker commands?

Setting more threads with "number of processes for parallel building" wont help with linking, becase linking one target is done only by one command. Number od processes will affect only compilation of more targets.

And btw. when the executable is linked, how large is it (filesize)?

[wilcomir]

no, I didn't try to compile it by command line... I don't even know how to however, te exe size is about 500kb... I think it is toooo much maybe it's something about static/dinamic linking?

thanks!

[zabzonk]

It's certainly not a hardware issue - I do my C++ development on an ancient Pentium III with 256Mb RAM, with no problems. A common cause of slowdowns like this is your anti-virus software scanning things it needn't - have you tried linking with your AV software disabled?

[wilcomir]

hi zabzonk! thanks for your tip, I'll try to disable my AV as soon as I'll be back to the university (I'm at home for the WE). however, I haven't experienced any other slowing...

thanks for helping!

[thomas]

have you tried linking with your AV software disabled?

Antivirus software may indeed be the problem. In particular Kaspersky and Norten will make your computer practically unusable for development, they're as bad or worse than the malware that they presumably prevent.

I've been using Kaspersky because you get indefinite free licenses for it from some big computer magazine here, and surely something that's free can't be so bad that it doesn't warrant the price, can it? This assumption is wrong. Kaspersky will increase compile times by about 3/4 and will render quad-core CPUs as well as low-latency storage such as a SSD RAID entirely useless. On top of that, it will perform some kind of "deep scan" on new executables that run immediately after being created (such as 100% of everything that comes out the IDE when you develop, duh), which will freeze the computer for 15-20 seconds.

Linking can already be a daunting task if no security malware is breaking your computer, as the linker has to fetch a lot of random tiny fragments from many files. You may see noticeable speedups if you use a ramdisk or a SSD to host your library files.

[zabzonk]

> Linking can already be a daunting task

Actually, my experience is that linking is almost always much faster than compilation and I try to organise my projects a set of libraries for this very reason. On my system, it takes approximately the same time to link a project of 45 object files, a couple of custom libraries and the standard libraries as it does to compile a couple of c++source files. Admittedly, my hardware is sclerotic, but I've seen the same thing on Solaris enterprise class servers.

[thomas]

Funny how much figures differ.

My machine compiles about 5-10 non-trivial C++ source files per second, being mostly bound by process startup and file access. Linking can, depending on what's in the project, take anywhere from 1-2 seconds for a smallish project, and up to 45-60 seconds for something big.

[zabzonk]

It seems to me that logically compiling should be slower than linking. Consider what a compiler has to do:

- open source file and shunt it through the preprocessor
- open all the #included header files - this will almost always be dozens and maybe hundreds
- parse the source from the files - this involves a lot of non-trivial pattern matching and database (symbol table) manipulation. If templates are used, their Turing-complete nature means that the compilation can take an arbitrary (or even infinite) amount of time.
- optimise the results of the parse
- write results to object file
- repeat for next source file

Compare this with the link process:

- open a  relatively small number of files (all the .o files and libraries) These are in binary format and so do not need any sophisticated parsing
- look up code by name - for the libraries at least, there are indexes to speed this up
- fix up the code - a simple linear process
- write code to single executable file

This is much less computationally and I/O intensive than compiling and so should be faster. Of course, not all linkers are as smart as we would like them to be - people seem to prefer to work on compilers, for some strange  reason :-), and linking cannot be as easily parallelised as the compilation process.

[wilcomir]

hi everybody!
I've tried to disable my AV, but nothing happened. it always takes over a minute to link a file... any other ideas?

thank you!

[zabzonk]

As someone else suggested, try linking from the command line to exclude CB from the equation. To do this:

a) Make sure that the GCC bin directory is on your path
b) Copy the link command line that gets displayed in the CB Build Log to a Windows command line prompt running in your  CB project's root directory.

In fact, it might be a good idea to post the link command line here too, so we can take a look at it.

[oBFusCATed]

hi everybody!
I've tried to disable my AV, but nothing happened. it always takes over a minute to link a file... any other ideas?

thank you!

Is you harddrive heavily fragmented?

[zabzonk]

> Is you harddrive heavily fragmented?

This shouldn't really make much difference - the linker does most of its work in memory. My ancient machine has a FAT32 file system I havent defragmented in years, but it has no linker speed problems.

[MortenMacFly]

any other ideas?

Try "process explorer" from "SysInternals" (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) and track what exactly happens during linking. Notice that you'll need to setup a filter properly so you only see the relevant parts. Otherwise you'll be flooded with information. ;-)

[Biplab]

have you tried linking with your AV software disabled?

Antivirus software may indeed be the problem. In particular Kaspersky and Norten will make your computer practically unusable for development, they're as bad or worse than the malware that they presumably prevent.

I've been using Kaspersky because you get indefinite free licenses for it from some big computer magazine here, and surely something that's free can't be so bad that it doesn't warrant the price, can it? This assumption is wrong. Kaspersky will increase compile times by about 3/4 and will render quad-core CPUs as well as low-latency storage such as a SSD RAID entirely useless. On top of that, it will perform some kind of "deep scan" on new executables that run immediately after being created (such as 100% of everything that comes out the IDE when you develop, duh), which will freeze the computer for 15-20 seconds.

I also have a similar experience. I am currently using K*spersky antivirus suite. It does increase the build time as it wants to freeze the whole pc to see if a newly created executable is a virus or not. For example when u run configure script in MSYS or in CygWin, every conftest.exe is checked for virus and other malwares. End result - super slow compilation.

I faced even other problem with it. While running a configure script under MSYS, it wants me to confirm that every process launched by sh.exe or any child process is safe to run or not. End result - millions of clicks to let it know that I want to run the configure script. Putting all related process to safe list yields no result.

I had to give up and resort to cross-compilation. When I really need to compile anything under MSYS, I have to turn off internet connection and antivirus & then everything compiles fine. Moral of the story is that antivirus programs are the most common culprit for pc slowdown.