public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Linking of C++ code takes a long time
@ 2006-05-31 23:59 Christian Nolte
  2006-06-23 11:21 ` Nick Clifton
  0 siblings, 1 reply; 3+ messages in thread
From: Christian Nolte @ 2006-05-31 23:59 UTC (permalink / raw)
  To: binutils

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I have a problem regarding linking of c++ code using a Fedora Core 5
system. It is
a normal sized (about 100 classes) autotools-project (CXXFLAGS=-O0 -g3),
built in debug-mode. 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), this is
also true for another ArchLinux-system and a WindowsXP-system (using the
M$ linker and compiler) I've tested. 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. Removing the
compiler-flag "-g3" has no effect too. Furthermore I have noticed that
during linking the CPU-load is only at about 80%. So I guess that there
is some I/O is going on which slows everything down.

Perhaps someone of you has an idea what could be the problem here and
what I could try to solve this issue.

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.3 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFEfchhCNjA0nfhW7wRAi77AKCbLpem6ocvI3ZGRHxvoHzfB7PoxwCfV1jC
OMGTcOxj9qEp3ycoz0cf5jo=
=ATga
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linking of C++ code takes a long time
  2006-05-31 23:59 Linking of C++ code takes a long time Christian Nolte
@ 2006-06-23 11:21 ` Nick Clifton
  2006-07-12 20:20   ` Christian Nolte
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Clifton @ 2006-06-23 11:21 UTC (permalink / raw)
  To: Christian Nolte; +Cc: binutils

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 ?  Did you try using the 2.16.91.0.6-5 
version on FC4 ?  If so was it still < 10 seconds for the link ?

Have you tried using any system profiling tools to find out what is 
going on ?  (vmstat, oprofile, etc)

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 ?

Anyway really if this is an OS issue, you ought to try asking on a 
Fedora list.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linking of C++ code takes a long time
  2006-06-23 11:21 ` Nick Clifton
@ 2006-07-12 20:20   ` Christian Nolte
  0 siblings, 0 replies; 3+ messages in thread
From: Christian Nolte @ 2006-07-12 20:20 UTC (permalink / raw)
  To: Nick Clifton; +Cc: binutils

-----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-----

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-07-12 20:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-31 23:59 Linking of C++ code takes a long time Christian Nolte
2006-06-23 11:21 ` Nick Clifton
2006-07-12 20:20   ` Christian Nolte

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).