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

[Roland Schwingel <roland@schwingel.com>]

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)?