Mail Archives: djgpp/2001/04/09/02:39:25
On Sun, 8 Apr 2001, Dennis Yelle wrote:
> > No, GDB doesn't slow down programs, unless the program does something
> > very special, such as issues a lot of DPMI function calls, or
> > generates lots of SIGFPE exceptions.
> >
> > Normal programs don't do that. But your program, especially its car5
> > function, allocates lots of memory in very small chunks (because it
> > creates lots of temporary Bset objects), which forces the library to
> > requests lots of small allocations from the DPMI server. Each such
> > allocation gets caught by GDB, because it needs to be aware of all
> > memory allocated by the program being debugged, to be able to
> > deallocate that memory if the program is restarted without exiting the
> > debugger. This causes a huge overhead, which is why you see this
> > terrible slowdown.
>
> Here is a much smaller program that also demonstrates
> a terrible slowdown under gdb. That is, the program
> below takes much more than 10 times as long to run under gdb.
[snip]
> After 20 seconds it has only produced 3 lines of output.
> The program does not allocate any memory in the
> function car7.
How do you know that it doesn't allocate memory? The only way to do
that is to put a breakpoint on the entry to the library function
`sbrk' and see if it is ever hit. Did you do that?
> Clearly there is something wrong somewhere.
> Can anyone tell me how to fix this?
I think I explained why this could happen. Why can't you look at the
assembly code produced for this problem and see what's going on? It's
not right to expect others to do all the footwork for you.
In any case, this only happens during debugging, so it's not a grave
problem, since you step the program anyway.
- Raw text -