[Bug gas/15295] gas rebuffer_line() routine (listing.c) issues excessive read syscalls

[jtison at us dot ibm.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15295

--- Comment #5 from Jim Tison <jtison at us dot ibm.com> 2013-03-26 17:35:53 
UTC ---
Hi Nick, 

Figuring there was something different about SLES 11 on the s390x architecture
(glibc-2.11), I went and tried this experiment with on my Fedora Core 9 x86_64
(yeah, okay, a little dated, running glibc-2.8, but if it works, why mess with
it?). I still get 46 million some-odd lseek syscalls over on s390x. 

Anyway, I see the same lseek behavior with oggenc.s I saw on s390x, it just got
done faster (Intel Core Quad @ 2.3 GHz):
strace -c as -o oggenc.o -alshd=oggenc.lst oggenc.s
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 84.33    0.901576           0  44516828           lseek
 13.94    0.149053           0   3243096           read
  0.61    0.006543           1      5594           write
  0.60    0.006428           0     17827        24 open
  0.18    0.001974           0     17799           munmap
  0.11    0.001133           0     17803           close
  0.09    0.001000        1000         1           unlink
  0.08    0.000883           0     17823           mmap
  0.05    0.000485           0     17803           fstat
  0.01    0.000092           0      1409           brk
  0.00    0.000000           0         8         6 stat
  0.00    0.000000           0         1           lstat
  0.00    0.000000           0         6           mprotect
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         2           fcntl
  0.00    0.000000           0         1           getrusage
  0.00    0.000000           0         1           arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00    1.069167              47856004        31 total

I can't explain why the vast difference between your results and mine should
exist, but I think my user will accept completion in 54s as opposed to 4m30s on
the s390x. Unless you hear from me within a couple of days (nobody's here today
to tell me if this is acceptable), you can call this closed. The lawyers aren't
going to let me send out the real code; but oggenc.c(s) illustrates the problem
on my side. It's fairly obvious to me you've done the best you can, and I'll
settle for under a minute real time. Code shouldn't be written like that
anyway. We do use gcc+binutils to compile our DSOs for our own OS/arch
(s390x-ibm-tpf) with our own custom non-dbx-style debugger. What's really
ironic is that the subject of this complaint is native Linux code and would
have to be debugged with gdb: I don't see what good a listing does; I think my
user is just stuck on a nasty habit. But the rules I have to work with are the
rules, and IMO you've gone far enough. I appreciate the quick responses and the
job you've done. Thanks very much!

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.