[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 143977] Stepping in debugger too slow
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2007-04-09 18:34:23
Message-ID: 20070409183423.4602.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=143977         




------- Additional Comments From apaku gmx de  2007-04-09 20:34 -------
> > I might be wrong, but the widgets don't know wether they are currently 
> > shown or not. 
> 
> I hope this can be changed then. 

I don't know wether it can be changed. I only had short looks into the debugger and \
its not really appealling to work on the code.

> > Apart from this bugreport you probably should also file a couple of BR's 
> > against gdb. 
> 
> Hmm, I have taken a quick look at the GDB reports and they seem very 
> technical. Do you think I can really file a report which basically 
> says "These commands are too slow"? 

I guess you should have at least some profiling information

> > because its slow like hell for no particular reason (I created 
> > profiling information for Vladimir and he couldn't understand why the 
> > most-called-functions are called that often). 
> 
> I'm just curious: How did you create the profiling information? Is Vladimir 
> still active in KDevelop/GDB development (haven't seen many commits lately). 

He's on IRC quite often although he seems to lack time for KDevelop hacking.

As far as generating the profiling information, I don't know exactly, but first thing \
was to build gdb with profiling support enabled. Then use a gdb command to enable \
profiling (maint set profile) before running the application and then run gprof over \
the created output. The output of that is then human readable.


[prev in list] [next in list] [prev in thread] [next in thread]