RE: Excessive link time with 2.16.1

RE: Excessive link time with 2.16.1

[David M. Lee]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

I tried binutils 2.17.50.0.2.  The link time was over 10 minutes.

I finally got it to run with the profiler.  Looks like the bulk of the
time is spent in qsort, called from bfd_elf_match_symbols_in_sections.

I've attached the output from gprof.

dave
<><


-----Original Message-----
From: H. J. Lu [mailto:hjl@lucon.org] 
Sent: Thursday, June 15, 2006 12:01 AM
To: David M. Lee
Cc: binutils@sourceware.org
Subject: Re: Excessive link time with 2.16.1


On Wed, Jun 14, 2006 at 10:06:15PM -0500, David M. Lee wrote:
> Interesting.
> 
> Here are the link times for the example mentioned in PR2342 and my
application for various binutils.  The patch helped a lot, but it's not
the only problem.
> 
>        | 2.15.94.0.2.2 |  2.16.1 | 2.16.1 +PR2342 patch
> -------+---------------+---------+---------------------
> slowld |    4m 17s     |  4m 16s |       15s
> myapp  |       11s     | 13m 03s |    1m 07s
> 
> So the patch definitely fixes the problem the 'slowld' example had,
and addresses most of the problem with myapp.
> 

The Linux binutils 2.17.50.0.2 includes that patch.


H.J.

CONFIDENTIAL: This email, including its contents and attachments, if any, are confidential. If the reader of this e-mail is not an intended recipient, you have received this e-mail in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail at [emailaddress@crossroads.com] and permanently delete the copy you received. Copyright and other intellectual property rights in its contents are the sole property of Crossroads Systems, Inc. Email transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of the message which arise as a result of email  transmission.  Although we routinely screen for viruses, addressees should check this email and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this email or any attachments.

[-- Attachment #2: gmon.txt.gz --]
[-- Type: application/x-gzip, Size: 56088 bytes --]

Re: Excessive link time with 2.16.1

[H. J. Lu]

On Mon, Jun 19, 2006 at 03:00:37PM -0500, David M. Lee wrote:
> I tried binutils 2.17.50.0.2.  The link time was over 10 minutes.
> 

Did you read and follow the release note?


H.J.

Re: Excessive link time with 2.16.1

[H. J. Lu]

On Wed, Jun 14, 2006 at 10:06:15PM -0500, David M. Lee wrote:
> Interesting.
> 
> Here are the link times for the example mentioned in PR2342 and my application for various binutils.  The patch helped a lot, but it's not the only problem.
> 
>        | 2.15.94.0.2.2 |  2.16.1 | 2.16.1 +PR2342 patch
> -------+---------------+---------+---------------------
> slowld |    4m 17s     |  4m 16s |       15s
> myapp  |       11s     | 13m 03s |    1m 07s
> 
> So the patch definitely fixes the problem the 'slowld' example had, and addresses most of the problem with myapp.
> 

The Linux binutils 2.17.50.0.2 includes that patch.


H.J.

RE: Excessive link time with 2.16.1

[David M. Lee]

Interesting.

Here are the link times for the example mentioned in PR2342 and my application for various binutils.  The patch helped a lot, but it's not the only problem.

       | 2.15.94.0.2.2 |  2.16.1 | 2.16.1 +PR2342 patch
-------+---------------+---------+---------------------
slowld |    4m 17s     |  4m 16s |       15s
myapp  |       11s     | 13m 03s |    1m 07s

So the patch definitely fixes the problem the 'slowld' example had, and addresses most of the problem with myapp.

I'll try and run with a profiler to see if I can figure out where all the time is being spent.

BTW: in order to apply http://sourceware.org/ml/binutils/2006-04/msg00329.html, I had to apply http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?r1=1.143&r2=1.144&cvsroot=src first.

dave
<><


-----Original Message-----
From: H. J. Lu [mailto:hjl@lucon.org] 
Sent: Tuesday, June 13, 2006 1:58 PM
To: David M. Lee
Cc: binutils@sourceware.org
Subject: Re: Excessive link time with 2.16.1


On Tue, Jun 13, 2006 at 01:09:57PM -0500, David M. Lee wrote:
> Unfortunately, no.
> 

I was wondering if it was the same as

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2342#c9


H.J.



CONFIDENTIAL: This email, including its contents and attachments, if any, are confidential. If the reader of this e-mail is not an intended recipient, you have received this e-mail in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail at [emailaddress@crossroads.com] and permanently delete the copy you received. Copyright and other intellectual property rights in its contents are the sole property of Crossroads Systems, Inc. Email transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of the message which arise as a result of email  transmission.  Although we routinely screen for viruses, addressees should check this email and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this email or any attachments.

Re: Excessive link time with 2.16.1

[H. J. Lu]

On Tue, Jun 13, 2006 at 01:09:57PM -0500, David M. Lee wrote:
> Unfortunately, no.
> 

I was wondering if it was the same as

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2342#c9


H.J.

RE: Excessive link time with 2.16.1

[David M. Lee]

Unfortunately, no.

dave
<><


-----Original Message-----
From: H. J. Lu [mailto:hjl@lucon.org] 
Sent: Tuesday, June 13, 2006 12:27 PM
To: David M. Lee
Cc: binutils@sourceware.org
Subject: Re: Excessive link time with 2.16.1


On Tue, Jun 13, 2006 at 09:54:43AM -0500, David M. Lee wrote:
> I'm trying to upgrade from binutils 2.15.94.0.2.2 to 2.16.1.  However,
> my link time goes up from 12 seconds to 15 minutes!  The link time
> increase seems to be peculiar to one application - other link times
> don't seem unusual at all.
> 
> I'm building a Linux cross compiler.  I'm using gcc-4.1.1.
> 

Do you have a self-contained testcase?


H.J.

CONFIDENTIAL: This email, including its contents and attachments, if any, are confidential. If the reader of this e-mail is not an intended recipient, you have received this e-mail in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail at [emailaddress@crossroads.com] and permanently delete the copy you received. Copyright and other intellectual property rights in its contents are the sole property of Crossroads Systems, Inc. Email transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of the message which arise as a result of email  transmission.  Although we routinely screen for viruses, addressees should check this email and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this email or any attachments.

Re: Excessive link time with 2.16.1

[H. J. Lu]

On Tue, Jun 13, 2006 at 09:54:43AM -0500, David M. Lee wrote:
> I'm trying to upgrade from binutils 2.15.94.0.2.2 to 2.16.1.  However,
> my link time goes up from 12 seconds to 15 minutes!  The link time
> increase seems to be peculiar to one application - other link times
> don't seem unusual at all.
> 
> I'm building a Linux cross compiler.  I'm using gcc-4.1.1.
> 

Do you have a self-contained testcase?


H.J.

Excessive link time with 2.16.1

[David M. Lee]

I'm trying to upgrade from binutils 2.15.94.0.2.2 to 2.16.1.  However,
my link time goes up from 12 seconds to 15 minutes!  The link time
increase seems to be peculiar to one application - other link times
don't seem unusual at all.

I'm building a Linux cross compiler.  I'm using gcc-4.1.1.

For the build machine:
[dmlee@hermes ~]$ uname -a
Linux hermes.commstor.crossroads.com 2.6.16-1.2115_FC4smp #1 SMP Mon Jun
5 15:01:20 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux

I configure both versions the same way:
CFLAGS="-O2" $(BINUTILS_PATH)/configure \
        --target=i686-linux \
        --prefix=$(INSTALL_PATH) \
        --libdir=$(INSTALL_PATH)/host-lib \
        --enable-64-bit-bfd \
        --disable-nls \
        --disable-multilib    

I configure gcc using:
CFLAGS="-O2" CXXFLAGS="-O2" $(GCC_PATH)/configure \
                --target=i686-linux \
                --prefix=$(INSTALL_PATH) \
                --with-headers=$(INSTALL_PATH)/i686-linux/include \
                --disable-nls \
                --enable-symvers=gnu \
                --enable-threads=posix \
                --enable-__cxa_atexit \
                --enable-languages=c,c++ \
                --enable-clocale=gnu \
                --with-local-prefix=$(INSTALL_PATH)/i686-linux \
                --disable-multilib \
                --enable-debug \
                --enable-debug-flags='-pg'

The app in question is C++ compiled with CXXFLAGS="-O3 -ggdb".

I did a quick run with Oprofile - most of the time is spent in mempcpy.
I've not been able to get much more information through profiling.

Help!
dave
<><

CONFIDENTIAL: This email, including its contents and attachments, if any, are confidential. If the reader of this e-mail is not an intended recipient, you have received this e-mail in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail at [emailaddress@crossroads.com] and permanently delete the copy you received. Copyright and other intellectual property rights in its contents are the sole property of Crossroads Systems, Inc. Email transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of the message which arise as a result of email  transmission.  Although we routinely screen for viruses, addressees should check this email and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this email or any attachments.