This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Linking of C++ code takes a long time
- From: Christian Nolte <ch dot nolte at fh-wolfenbuettel dot de>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Wed, 12 Jul 2006 22:20:42 +0200
- Subject: Re: Linking of C++ code takes a long time
- References: <447DC861.2060308@fh-wolfenbuettel.de> <449BAC7E.703@redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Nick,
thank you for your reply! I've had not much time at hand lately,
therefore this late response.
Nick Clifton schrieb:
> Hi Christian,
>
>> When it comes to the linking stage, linking takes
>> about 1.30 minutes (2.4 GHz Athlon). Using a FC4-system with all the
>> latest updates, linking takes about 10 seconds (1.8 GHz Athlon),
>
>> The linking time is reproducible slow on
>> a second FC5-system (1.8 GHz Intel dual-core CPU).
>
>> First I thought that there could be a binutils issue and I tried a
>> downgrade of binutils-2.16.91.0.6-5 (FC5) to binutils-2.15.94.0.2.2-2
>> (FC4) but this did not solve the problem.
>
> So you appear to be saying that the cause in the slowdown is the OS and
> not the version of the linker ?
This could be the case. Perhaps it is a kernel issue. But this seems to
be very unlikely.
> Did you try using the 2.16.91.0.6-5
> version on FC4 ? If so was it still < 10 seconds for the link ?
I have not tried this and unfortunately I have no access to a FC4
machine to try it at the moment.
> Have you tried using any system profiling tools to find out what is
> going on ? (vmstat, oprofile, etc)
I did some oprofile'ing lately with this result:
- ---
CPU: Athlon, speed 2008.97 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 100000
samples % image name app name
symbol name
1827378 23.4589 libc-2.4.so libc-2.4.so mempcpy
1512442 19.4160 no-vmlinux no-vmlinux (no
symbols)
1157262 14.8563 libc-2.4.so libc-2.4.so
msort_with_tmp
809429 10.3910 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
elf_sort_elf_symbol
745444 9.5696 libc-2.4.so libc-2.4.so memcpy
325840 4.1830 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
bfd_elf32_swap_symbol_in
300832 3.8619 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
bfd_getl32
86843 1.1148 ld ld
match_simple_wild
67714 0.8693 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
bfd_getl16
61787 0.7932 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
bfd_elf_get_elf_syms
49999 0.6419 Xorg Xorg (no
symbols)
49051 0.6297 libbfd-2.16.91.0.6.so libbfd-2.16.91.0.6.so
bfd_elf_match_symbols_in_sections
41861 0.5374 make make (no
symbols)
40447 0.5192 libglib-2.0.so.0.1000.3 libglib-2.0.so.0.1000.3 (no
symbols)
40199 0.5161 libqt-mt.so.3.3.6 libqt-mt.so.3.3.6 (no
symbols)
35683 0.4581 oprofiled oprofiled (no
symbols)
...
- ---
This profiling data has been sampled during linking only. I have simply
removed the binary and did a make. The time for linking is about 1.30
min. on this machine. I can see nothing unusual here. I/O was idle
during linking. No relevant background jobs were running.
> Do have other background processes running on the FC5 machine that you
> do not have running on the FC4 machine ? Are you using NFS mounts ?
No and no.
> Anyway really if this is an OS issue, you ought to try asking on a
> Fedora list.
I have already done this without much success.
Best regards
Christian
- --
Christian Nolte
key : http://www.noltec.org/christian-nolte.asc
or : www.keyserver.net
- ----------------------------------------------------------------------
The Information Revolution will be fought on the command line.
- ----------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFEtVmaCNjA0nfhW7wRAth2AKCaMfOqHyLzJQfyf32Lotvcb82SxQCg7NI0
Od+ooL4YDzOS8AiKG/pVstA=
=1tCz
-----END PGP SIGNATURE-----