Re: performance of multithreading gets gradually worse under gdb

[Michael Snyder <msnyder at vmware dot com>]

Markus Alber wrote:
>  Hello,
>
>  I have experienced the following problem:
>
>  I'm debugging a number-crunching application which spawns a lot (36) 
>  little
>  worker threads per iteration. The system does typically OoM 200 
>  iterations.
>  Although each of them should take about the same amount of time, the 
>  performance
>  gets worse with every iteration and becomes excruciatingly slow.
>
>  A system monitor reveals that gdb allocates more memory with every 
>  iteration,
>  i.e. with every 36 threads started and finished. The CPU load of GDB 
>  goes up, too.
>  The CPU usage of the application goes down. Compared to the solo 
>  performance, it
>  gets slower by a factor 20 and more, if run long enough.
>
>  The application behaves perfectly when run by itself. The 
>  multi-threaded part is not
>  debugging compiled when this behaviour occurs.
>
>  The distribution is SuSE 11.3 / gdb 7.1.
>
>  Is there anything I can change about this behaviour, any options of gdb 
>  that need to
>  be set in these circumstances?

Interesting.

By how much does gdb's memory allocation increase?
In total or, if possible, per iteration?  This might
give is a clue as to where to look.

Do you think you could write a simple sample program that
allocates threads in a manner similar to your application?

Thanks,