From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Andrew Cagney Cc: Kimball Thurston , gdb@sources.redhat.com Subject: Re: gdb and dlopen Date: Wed, 17 Oct 2001 11:15:00 -0000 Message-id: <20011017141550.B10927@nevyn.them.org> References: <20011016161525.A1241@nevyn.them.org> <20011016213252.A8694@nevyn.them.org> <20011016220353.A9538@nevyn.them.org> <3BCCF83F.8010401@cygnus.com> <20011017010849.A23345@nevyn.them.org> <3BCDA6CF.3000308@cygnus.com> X-SW-Source: 2001-10/msg00178.html On Wed, Oct 17, 2001 at 11:42:07AM -0400, Andrew Cagney wrote: > >thread_db is, plain and simply, horribly slow. We could speed it up > >tremendously if we cached memory reads from the child across periods > >where we knew it was safe to do so; I'll have to think about how to do > >this. Meanwhile, the real speed penalty seems to be: > > Look at dcache.[hc]. Well, if I use dcache by creating an appropriate memory region, I go from 7.17 seconds execution time to 5.46 seconds. We still do a load of unnecessary memory traffic, but at least it isn't quite so heinous. Is there any reason not to define a Unix inferior process's memory space as cached by default? I suppose that for mmap'd regions and for SYSV style shared memory we might lose, but I consider still consider this a reasonable behavior, worth documenting but not worth accepting a performance penalty for. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer