Re: Slow linking for ARM

[Richard Earnshaw <rearnsha at arm dot com>]

On 25 Dec 2010, at 09:13, "Titus von Boxberg" <titus@v9g.de> wrote:

> Bill, Bryan, all,
> Am 24.12.2010 um 23:04 schrieb Bill Pringlemeir:
> 
>> Ok.  Now you are saying 20-30%, I thought it was 20x as long
>> previously, but maybe you said 20%?
> For completeness, here is a summary of my observations:
> I'm building for ARM, X86 and PPC, all Linux-ELF-glibc.
> Originally, I use ld of binutils-2.20.
> The compiler is gcc 4.5.1.
> The host OSes are 32-bit-X86-Linux and 64-bit-Intel-MacOS.
> The measurements have taken place on MacOS, but for binutils-2.20
> the feeling is not different on Linux.
> The software is C++, with modest to high template usage.
> I have about 15 applications; all but two of them are
> portable between the architectures. This is how I compare
> the linking times for the architectures.
> All times compared are "user" times.
> Comparison took place compiling and linking the software with -g
> When not using -g the absolute times and also in some cases the
> factor between ARM and PPC/X86 are reduced.
> 
> With ld-2.20 I observe:
> - all software works.
> - ld for ARM is always slower than for PPC/X86
> - ld for PPC and X86 always use roughly the same time.
> - The user time ratio between ld for ARM and for PPC/X86 varies
>  between 2 and about 25. The initially given factor of 4 was just a rough
>  average. Initially, I only was curious why ARM takes longer
>  than other archs.
> - For most of my applications the factor is about 3-4.
> - I have one kind of application where the factor and ARM linking time
>  explodes to roughly 25 to 30 and the absolute time is about 200s.
>  (This is the case when compiling and linking with -g.)
> - with boost's asio lib http server example the factor is roughly two.

It would really help if you could obtain some execution profiles of the linker for the case that is taking so long.  Especially if you can get them for both ARM and another target. It might be something really dumb going on.

R.

> 


--
For unsubscribe information see http://sourceware.org/lists.html#faq