This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb/Insight 5.3 really slow when stepping - Now solved (fix included)!
- From: Roland Schwingel <Roland dot Schwingel at onevision dot de>
- To: gdb <gdb at sources dot redhat dot com>
- Date: Thu, 22 May 2003 18:15:59 +0200
- Subject: gdb/Insight 5.3 really slow when stepping - Now solved (fix included)!
- Organization: OneVision Software AG
Hi. again....
Yesterday I posted the attached problem here. At the same time I started
out to
track down the problem on my own. And I think I found it. When using gdbtk
stepping is now as fast as when using commandline gdb or the tui interface.
The problem is IMHO in the gdb_find_file_command() function in
gdb/gdbtk/generic/gdbtk-cmds.c
I am quite unfamiliar with gdb's internals and maybe I have ruined
something but maybe not.
I hope this is the right place to publish my fix.
From what I have understood gdb_find_file_command() is used from gdbtk
to find the
fullname of a file and check its presence. It is doing this by calling
lookup_symtab().
This lookup_symtab() call appears to be that expensive and *terribly*
slowed down
operations and causing all these filesystem lookups. (look into my
attached previous
posting). I found that I always got an already full qualified filename
as argument to
gdb_find_file_command(). So I introduced a shurtcut to check whether
the supplied
argument is already fully qualified and when this is the case just check
with stat() its
presence. When all this is succesful, the lookup_symtab() call is
skipped elsewise
everything goes its regular way.
In code it looks the following (I am referencing current CVS version of
this file here):
I first added a
#include "filenames.h"
on line 38.
gdb_find_file_command() starts at line 1035.
There is are 2 lines
filename = Tcl_GetStringFromObj (objv[1], NULL);
st = lookup_symtab (filename);
I added the following code between these 2 lines:
============= snip =================
/* First check whether the given file is already fully qualified
and check presence */
fullname = NULL;
if (IS_ABSOLUTE_PATH (filename))
{
struct stat st;
const int status = stat (filename, &st);
if (status == 0)
{
if (S_ISREG (st.st_mode))
fullname = filename;
}
}
if (fullname == NULL)
{
============= snip =================
and a line
}
right after the already mentioned
st = lookup_symtab (filename);
which is at present in line 1048. From now on gdbtk is also really fast..
I hope some maintainers are reading this list and can maybe apply my
changes to the CVS, so
that other can also benefit from it. If not maybe someone can give me a
hint whom to contact.
Thanks,
Roland
__________________
Hi....
I am using gdb/insight 5.3 on windows (cygwin). And it is *really* slow
when stepping...
So I started out to detect where it is slow. Even on stupid lines eg.
stepping
thru this block (snipped out of Insight)
- 2370 int numLines = 0;
2371 NSArray *predefinedNames;
- 2372 BOOL mustGenNames = NO;
On every step gdb/insight is doing (in my case) about 17800 (!)
filesystem accesses.
I used FileMon from SysInternals. Obviously it checks presence of the
source file
and a huge number of headers and other source files. Both system header
and selfmade onces.
This makes stepping *really* slow. I encountered that it depends on the
file you are
stepping thru in how slow it is.
Is this checking necessary all the time (on every step)? Wouldn't it be
enough to scan
all these things just once when entering the file the first time? Can it
be switched off?
Thanks for your help,
Roland