performance of multithreading gets gradually worse under gdb

[Markus Alber]

 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