|
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.
Cheers Nick
listing.c.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |