public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* gdb/Insight 5.3 really slow when stepping - Now solved (fix included)!
@ 2003-05-22 16:16 Roland Schwingel
  0 siblings, 0 replies; only message in thread
From: Roland Schwingel @ 2003-05-22 16:16 UTC (permalink / raw)
  To: gdb

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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-05-22 16:16 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-22 16:16 gdb/Insight 5.3 really slow when stepping - Now solved (fix included)! Roland Schwingel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).