Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Roland Schwingel]

Hello Keith (and all lists this mail goes to... :-)

 > On Fri, 2003-05-23 at 02:42, Roland Schwingel wrote:
 > > The last 2 days I made 2 postings here. Maybe they were not correctly
 > > targeted. I today found the
 > > gdb-patches mailinglist where I just sent a diff to concerning the gdbtk
 > > stepping problem.
 >
 > Well, strictly speaking the patch should go to the insight list (insight
 > at sources dot redhat dot com), where I would see it.
Sorry I am not very familiar with the dependencies... I saw gdbtk issues
in the standard gdb list, so I first thought I would be right here...

 > However, I have to question why lookup_symtab is suddenly so painfully
 > slow? I don't have a problem applying the patch, but I want to make sure
 > first that you didn't uncover a real gdb problem that no one knows
 > about.
Well... What shall I say. I (we) are using gdb (using gdbtk ui) since
gdb 5.0. And constantly gdb got slower from version to version. Recently
I updated the gdb which is used here inhouse to 5.3 (from 20030303 -
same source which is also used in native cygwin) and I noticed it got
even slower. Stepping from one line of code to the other took between
2 and 20 seconds (depending on the file which was visible). So after
seeing that it goes to be unusable I started out to track this
problem down. I started FileMonitor from SysInternals to watch disk
activity and watched whats happening. I saw on every step thousands
of filesystem open/getinfo/close events. It seems to me that it tries
to get infos for every object/type/symbol referenced by the current
file on every lookup. It tries to do this for lots of .h/.c/.m files
which are in any kind related to the current file. I don't know why
lookup_symtab() is doing this... The amount of lookups differs from
file to file which is showing in the sourcewin of gdbtk.

Finally when looking at gdb_find_file_command() which calls this
lookup_symtab() on every step, I saw that the sole purpose
of this function appears to be getting the full path of a file. When
stepping all the time the pathname was already fully qualified, so
when this is the case just check the presence of the file and then
return with the filename as full name if ok. Elsewise go the regular
way using lookup_symtab(). That is what my patch is doing now. I
think gdbtk uses this on every step to determin whether a file has
changed or not.

 > Hmm. You say you did this on 5.3 (for native cygwin?). What about a
 > newer version  -- have you tried a CVS snapshot or HEAD?
Yes I use the current gdb of cygwin (20030303), with a bunch of changes
to allow Objective C debugging. But it is also slow without these changes.
I will try to get the time to compile the current version. I checked out
head today... Unfortunately I am very busy with other stuff. I can't promise
it.

 > I used to use cygwin a lot around 5.3 time frame -- it was never that
 > slow. If I asked for a testcase which demonstrates the problem, do you
 > think you could provide me with one?
Puh.. Lets see whether I can construct one. We are using Objective C a lot,
maybe its related to this... And our applications are heavily multi threaded
and are relativly big about 30.000 files need to get compiled to get them
running. Our apps are mingw apps. I just use the cygwin gdb (from a fully
working cygwin environment)

Thanks for your help.

Roland

PS: I fixed another bug in gdbtk, where the filecombobox in the sourcewindow
     is not always showing all files. After doing a dynamic load the filenames
     which are brought by the newly loaded lib where missing.The fix apears
     to be easy. Where should I direct it to (the insight list or gdb-patch)?

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Keith Seitz]

On Fri, 2003-05-23 at 05:57, Roland Schwingel wrote:

> Finally when looking at gdb_find_file_command() which calls this
> lookup_symtab() on every step, I saw that the sole purpose
> of this function appears to be getting the full path of a file. When
> stepping all the time the pathname was already fully qualified, so
> when this is the case just check the presence of the file and then
> return with the filename as full name if ok. Elsewise go the regular
> way using lookup_symtab(). That is what my patch is doing now. I
> think gdbtk uses this on every step to determin whether a file has
> changed or not.

I'll have to think about this, but when you put it that way, it does
rather sound like the stat idea isn't altogether out of place. Let me
give it some thought.

> Yes I use the current gdb of cygwin (20030303), with a bunch of changes
> to allow Objective C debugging. But it is also slow without these changes.

Hmm. Maybe there's a problem in the symbol readers for ObjC? Maybe
there's just TONS of symbols. Admittedly, I don't use Insight for much
else other than small dynamic modules and gdb itself. So maybe your
large environment is causing the problems, too. (Sigh -- there's no easy
way to know, is there?) In any case, it seems like short-circuiting
lookup_symtab in gdb_find_file might be appropriate.

> PS: I fixed another bug in gdbtk, where the filecombobox in the sourcewindow
>      is not always showing all files. After doing a dynamic load the filenames
>      which are brought by the newly loaded lib where missing.The fix apears
>      to be easy. Where should I direct it to (the insight list or gdb-patch)?

Yes, submit to this (insight) list. I officially own libgui (see
src/MAINTIANERS). Unless the patch is pretty trivial, you will need an
FSF assignment... 

Keith

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Andrew Cagney]

I wonder.

For cygwin, a file can't be deleted unless it is closed.  This causes 
problems when GDB has the executible open (for symbols) when in another 
window the user is trying to do make.

Did GDB or Insight get modified to close the file, and if it did, could 
that be causing the open/close?

Andrew

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Roland Schwingel]

Hi...

Andrew Cagney wrote:
> I wonder.
> 
> For cygwin, a file can't be deleted unless it is closed.  This causes 
> problems when GDB has the executible open (for symbols) when in another 
> window the user is trying to do make.
> 
> Did GDB or Insight get modified to close the file, and if it did, could 
> that be causing the open/close?

In this case gdb did not try to open executables. It tried to open source
files (.c/.h/.m files in particular). On success it did nothing else then getinfo
and close...

Roland

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Roland Schwingel]

Hi ....

insight-owner@sources.redhat.com wrote on 23.05.2003 15:15:48:

 > > [description of gdb_find_file_command() patch]
 >
 > I'll have to think about this, but when you put it that way, it does
 > rather sound like the stat idea isn't altogether out of place. Let me
 > give it some thought.
Ok.. I hope you are coming to the same conclusion then me...

 > > Yes I use the current gdb of cygwin (20030303), with a bunch of changes
 > > to allow Objective C debugging. But it is also slow without these 
changes.
 >
 > Hmm. Maybe there's a problem in the symbol readers for ObjC? Maybe
 > there's just TONS of symbols. Admittedly, I don't use Insight for much
 > else other than small dynamic modules and gdb itself. So maybe your
 > large environment is causing the problems, too. (Sigh -- there's no easy
 > way to know, is there?)
Unfortunately not. But maybe it is related to Objective-C... And the 
huge amount
of code we have... I am not really familiar with gdbs internals. I just 
applied the
Objective C Patches from time to time to the individual current version 
which caused
more or less work, so I am not 100% virgin to gdbs internals but far 
away from
being a guru here....

 > In any case, it seems like short-circuiting lookup_symtab in 
gdb_find_file might be appropriate.
I think so too. I designed the patch that way that if stat() fails it 
goes the normal way thru
lookup_symtab() so no bad side effects should be feared.
 
 > > PS: I fixed another bug in gdbtk, where the filecombobox in the 
sourcewindow
 > >      is not always showing all files. After doing a dynamic load 
the filenames
 > >      which are brought by the newly loaded lib where missing.The 
fix apears
 > >      to be easy. Where should I direct it to (the insight list or 
gdb-patch)?
 >
 > Yes, submit to this (insight) list. I officially own libgui (see
 > src/MAINTIANERS). Unless the patch is pretty trivial, you will need an
 > FSF assignment...
I think this would be no problem...
Anyway my patch for this is just adding 2 lines to srcwin.itb.
I will submit it separately and of course I am not claiming any rights
on my patches...

Roland

Re: gdb/Insight 5.3 really slow when stepping - patch submitted to gdb-patch list

[Keith Seitz]

On Fri, 2003-05-23 at 02:42, Roland Schwingel wrote:
> The last 2 days I made 2 postings here. Maybe they were not correctly 
> targeted. I today found the
> gdb-patches mailinglist where I just sent a diff to concerning the gdbtk 
> stepping problem.

Well, strictly speaking the patch should go to the insight list (insight
at sources dot redhat dot com), where I would see it.

However, I have to question why lookup_symtab is suddenly so painfully
slow? I don't have a problem applying the patch, but I want to make sure
first that you didn't uncover a real gdb problem that no one knows
about.

Hmm. You say you did this on 5.3 (for native cygwin?). What about a
newer version  -- have you tried a CVS snapshot or HEAD?

I used to use cygwin a lot around 5.3 time frame -- it was never that
slow. If I asked for a testcase which demonstrates the problem, do you
think you could provide me with one?

Keith