[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gas new (2.20) rebuffer_line() excessive read() syscalls

From: nick clifton
Subject: Re: gas new (2.20) rebuffer_line() excessive read() syscalls
Date: Fri, 22 Mar 2013 14:03:40 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16

Hi Jim,

I've got a C language source code TU that is 1.3 MiB large. I didn't
write it (I know better), but I have to make it coexist in a rather
lengthy system build, and the leader of the system build team is
justifably upset with me.

As we see, the compilation time grows by a factor of 15X. I see the
rebuffer_line() (listing.c:541) routine

Since this function is only used by the listing code, you could just not enable listing when assembling your huge application...

It looks like most of listing.c was rewritten for 2.20. I tried removing
the fseek(FILE *, 0, SEEK_SET) call and made a couple of refactoring
changes to make sure I'm seeking  the proper source line.

Unfortunately your patch does not work. It removes the fseek and rereading of the source file, but it does not actually search backwards to find an earlier line, which is the entire point of the rebuffer_line() function.

Instead, please could you try out the attached patch and let me know if it works for you.


Attachment: listing.c.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]