Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?

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.