Re: performance of multithreading gets gradually worse under gdb

[Markus Alber <markus at hyperion-imrt dot org>]

On Thu, 03 Feb 2011 12:26:25 -0800, Michael Snyder wrote:
> Markus Alber wrote:
> > I compiled gdb-6.5 alright and it performs well as usual, without 
> > this problem.
>
> Good info.  What version of gdb were you using when you detected the 
> problem?

it was gdb 7.1 as it comes with OpenSuSE 11.3

Meanwhile I tried every release between 6.5 and 7.2. All the 7's showed 
the
problem, but it was also perceivable with 6.8.91.
I was a bit too quick to assert that 6.5 was working well... it wasn't 
possible
to set break points, some 6.8 versions crashed. There seems to be some 
incompatibility
between the compiler on OpenSuse 11.3 and the older gdbs (I got them as 
sources from
the gnu repository)

> I ran your program stand-alone, then under gdb 7.0, then gdb 7.2CVS.
> On my not-so-new system I got the following times:
> stand alone: 15m33s
> gdb 7.0      16m
> gdb 7.2CVS   16m10s

So I presume the stripping-down removed something that causes the 
problem in the
larger application. Or, is it a possibility that it has something to do 
with the kernel or compiler of
OpenSuSE 11.3?

Meanwhile I've gone back to my older 4-core machine running gdb 6.5 on 
OpenSuse 10.2.
Performance is constant throughout. I did notice that gdb allocates 
memory for each
iteration.



> I could not perceive any change in the cycle time from beginning to 
> end.
>
> GDB 7.0 did increase its memory footprint by about 3mb during the run
> (3 percent).  So that could indicate some leakage, around 15k per 
> cycle.
> But I can't see that as the main reason for the slow-down you're
> reporting, considering that your system is not memory bound.
>
> GDB 7.2CVS increased its memory footprint by only about 500kb during 
> the
> whole run, so you might consider giving that a try.  Instructions for
> getting the latest development sources are here:
>
> http://sourceware.org/gdb/current/
>
> If you'd be willing to contribute your little sample program, we
> might be able to use it for a thread debugging stress test or
> something.
>
> Michael