This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- From: Paul Smith <psmith at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 22 May 2013 15:19:59 -0400
- Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- References: <1368733335 dot 4101 dot 743 dot camel at pdsdesk> <51960329 dot 2010802 at redhat dot com> <1369248335 dot 7209 dot 151 dot camel at homebase>
- Reply-to: psmith at gnu dot org
On Wed, 2013-05-22 at 14:45 -0400, Paul Smith wrote:
> I've just got this case working now, so I'll look into what's going on
> here more.
OK, some quick info from strace: the fast GDB does about 400 system
calls for the first iteration of the loop, in 0.024 seconds. It does
124 lseek(), 177 read(), and 101 rt_sigprocmask() system calls.
The slow GDB does 20773 system calls in 4.4 seconds for the first
iteration. It does 6914 lseek(), 13757 read(), and 101 rt_sigprocmask()
system calls (plus the write of the results).
The interesting thing is both versions are constantly seeking and
reading to exactly the same location, over and over again. However GDB
4.6 does it many times more than GDB 7.5.1. For example, I get this
combo:
14:51:34.423582 lseek(7, 26763264, SEEK_SET) = 26763264 <0.000004>
14:51:34.423609 read(7, "P\361\236\0\0\0\0\0`\361\236\0\0\0\0\0p\361\236\0\0\0\0\0\200\361\236\0\0\0\0\0"..., 4096) = 4096 <0.000015>
6838 times during the slow run (exact same offset value, exact same read
request and response), and this one:
14:52:16.842408 lseek(14, 26763264, SEEK_SET) = 26763264 <0.000004>
14:52:16.842435 read(14, "P\361\236\0\0\0\0\0`\361\236\0\0\0\0\0p\361\236\0\0\0\0\0\200\361\236\0\0\0\0\0"..., 4096) = 4096 <0.000004>
48 times during the fast run. BTW I checked and those FDs are for the
executable in both runs. I'm not sure why they're opened in a different
order.
Seems like it's time to do some test builds against the git tree.