slooooow linking

[Ceniza]

The linking stage can take a fairly huge amount of time. It all depends on the options, libraries and code itself.

At work I am using Intel C++ to compile the release version of the project I am working on (Visual C++'s linker either crashes with some decent optimizations, or it produces wrong code that crashes at runtime). For the release version I have some aggressive options set, including /Qipo and generating both generic code and target optimized code. Just compiling the source code can take a few minutes, but the linking stage takes more than 20 minutes. It takes it time to load all needed information (eating more than 1 GB of RAM in the process), and then it takes it more time to produce the DLL. Add to that that it does it twice (I guess once for each target).

Linkers are not always as dumb as one may think, and that costs time.

[wilcomir]

hi all!

here's the command line displayed while compiling and linking

mingw32-g++.exe    -c "C:\Documents and Settings\Vladi\Documenti\cpp\prova.cpp" -o "C:\Documents and Settings\Vladi\Documenti\cpp\prova.o"
mingw32-g++.exe  -o "C:\Documents and Settings\Vladi\Documenti\cpp\prova.exe" "C:\Documents and Settings\Vladi\Documenti\cpp\prova.o"  
Process terminated with status 0 (1 minutes, 19 seconds)
0 errors, 0 warnings

I do not think my hard drive is heavily fragmented, the laptop is new, less than a month, and the hard disk is practically empty. however I'm trying to link without cb, I'll let you know.

thanks!

EDIT I've tried linking from cmd, and it's as slow as with cb. moreover, it produced an error:

collect2: cannot find '1d'

that disappeared as I've added the minigw bin path to the ambient variable PATH

any other ideas?

thanks again!

[koso]

Thats very strange, especialy when prova.o isn't extremly large.

Can you provide some minimal example / source code? And also compiler version .. "mingw32-g++ -v"

[zabzonk]

> I've tried linking from cmd, and it's as slow as with cb

So it looks like this is not a CB issue - I still suspect that it as an AV or similar issue with your specific laptop hardware and/or software. You may well be better off asking this question in a forum where you will get a wider audience than you will here - I suggest trying StackOverflow at  http://stackoverflow.com.

[wilcomir]

hi all!
here's what's produced when I write mingw32-g++ -v:

Code

C:\Documents and Settings\Vladi>mingw32-g++ -v
Reading specs from C:/Programmi/CodeBlocks/MinGW/bin/../lib/gcc/mingw32/3.4.5/sp
ecs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as -
-host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar
ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena
ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync
hronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special)

and here's what I always compile & link:

Code

#include <iostream>
using namespace std;

int main () {
    cout << "insert a number";
    int n;
    cin >> n;
    cout << 2*n;
}

the .o file is about 2kb, while the generated .exe is nearly 500kb

thanks!

[stahta01]

hi all!
here's what's produced when I write mingw32-g++ -v:

Code

C:\Documents and Settings\Vladi>mingw32-g++ -v
Reading specs from C:/Programmi/CodeBlocks/MinGW/bin/../lib/gcc/mingw32/3.4.5/sp
ecs
Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as -
-host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --
enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shar
ed --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --ena
ble-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-sync
hronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special)

and here's what I always compile & link:

Code

#include <iostream>
using namespace std;

int main () {
    cout << "insert a number";
    int n;
    cin >> n;
    cout << 2*n;
}

the .o file is about 2kb, while the generated .exe is nearly 500kb

thanks!

Debugging and library code increases size.

Tim S.

[wilcomir]

Debugging and library code increases size.

Tim S.

So what do you suggest?

thanks!

[thomas]

the .o file is about 2kb, while the generated .exe is nearly 500kb

According to your commandline, you are not generating any symbols and not linking to any external libraries. Thus, a program with a 2 kB object file should have minimum PE size, i.e. 4 kB. If it doesn't, then maybe you have some malware on your computer which adds that code (possibly several ones, since 500 kB is quite a lot).

To be sure it really isn't just debug symbols, though, rename the prova.exe to something that doesn't look like a program, for example prova.txt.
Then run strip prova.txt. If the program is now about 4kB, all is good, then the increased size was only due to debug symbols. If it's still around 500 kB and it was really created from a 2 kB object file with a commandline as described above, then you may want to ring the alarm bells.

[MortenMacFly]

the .o file is about 2kb, while the generated .exe is nearly 500kb

Then run strip prova.txt. If the program is now about 4kB, all is good, then the increased size was only due to debug symbols. If it's still around 500 kB and it was really created from a 2 kB object file with a commandline as described above, then you may want to ring the alarm bells.

Same here. I am using TDM's GCC 4.4.1(2). The file is as described, not linked against any additional libs (at least that's my purpose).
-> After compilation / linking: ~ 980 kB
-> After strip: ~500 kB.
Same thing with GCC 3.4.5:
-> After compilation / linking: ~ 500 kB
-> After strip: ~280 kB.

However - looking at was the linker accesses I see:
- crtbegin.o / crtend.o
- crt2.o
- libstdc++.a
- libmingw32.a
- libgcc.a
- libmoldname.a
- libmingwex.a
- libmsvcrt.a
- libuser32.a
- libkernel32.a
...which are all quite big in size.
If I look at the symbols of the final stripped exe I see references to MSVCRT and others.

However - my computer is 100% virus free, the same applies in a VM without network connection.

So what...?! I have this feeling that this discussion will lead to nowhere.

[thomas]

Surprising. Most of these should add nothing or next to nothing in my opinion, unless you really enforce it by using ultra-fat components of libstdc++. user32, kernel32, or msvcrt for example will only add some thunks for functions that your program actually uses, that's a few bytes for a small program (8 bytes per thunk unless you force alignment to be more than that), and maybe a kilobyte or two top for pretty much every program. libstdc++ can certainly add a few hundred kilobytes, but only if you actually use the stuff (and then it's not surprising).

I've just looked what the unit test program to one of my containers compiles to, as that's pretty much the smallest non-helloworld project I have at hand. Gcc 4.4.0-tdm turns roughly 10 kB of sources (not counting system headers) into a 8.5 kB object file, and this into a 33 kB executable. That includes around 7 kB for the main program using std::vector, and 1 kB for exception handling. It takes well under a second to compile and link. Gcc 4.4.1-tdm produces considerably larger executables, though I don't have it installed now, so can't tell for this example.

Well, whichever it is, you're probably right insofar as we'll not likely be able to tell why wilcomir's executables are that big.

[wilcomir]

According to your commandline, you are not generating any symbols and not linking to any external libraries. Thus, a program with a 2 kB object file should have minimum PE size, i.e. 4 kB. If it doesn't, then maybe you have some malware on your computer which adds that code (possibly several ones, since 500 kB is quite a lot).

To be sure it really isn't just debug symbols, though, rename the prova.exe to something that doesn't look like a program, for example prova.txt.
Then run strip prova.txt. If the program is now about 4kB, all is good, then the increased size was only due to debug symbols. If it's still around 500 kB and it was really created from a 2 kB object file with a commandline as described above, then you may want to ring the alarm bells.

hi, I did as you say, now the exe is 270kb in size.. still too much i believe... maybe I'll solve using another compiler, but wich one?

thanks everybody