Re: [Nemiver-list] Nemiver Speed
- From: Dodji Seketeli <dodji domain hid>
- To: Don Scorgie <Don domain hid>
- Cc: nemiver-list domain hid
- Subject: Re: [Nemiver-list] Nemiver Speed
- Date: Mon, 28 Jan 2008 09:39:20 +0100
Hello Don,
On Wed, Jan 16, 2008 at 07:28:13PM +0000, Don Scorgie wrote:
> (I'm not subscribed, so please CC me on any replies)
Okay, no problem. Sorry for the delay. You mail got stuck in the moderation
queue of this list for a little while, and I am very sorry for this.
>
> I made a comment on my blog about nemiver being slow [1] and was asked
> to explain myself ;)
Thank you for following up.
>
> I'm using Nemiver 0.4.0-ubuntu4 (default in Ubuntu Gutsy) with gdb 6.6.
> My prior experience with visual debugging is using WinDbg [2] for kernel
> debugging on Windows.
Okay.
>
> The slowness I've seen is when stepping through and into functions.
> When stepping through, the interface seems to take some time to respond
> - the toolbar is unresponsive for a few seconds each step. Stepping
> into functions seems to be the same. My initial thought was that
> Nemiver is querying gdb for each local variable again.
Ah okay. I *think* you are hitting a known bug on debian based systems.
You should try to install the libc6-dbg package on your system and try
again. It might fix the problem. I did hunt the problem some while ago, and
if you are interesting in knowing the details, you can read this (long)
thread: http://www.cygwin.com/ml/gdb/2007-01/msg00012.html
>
> Some numbers, if that helps at all. Debugging yelp from SVN head.
> Stepping into or over in a function takes around 4 seconds [3] before
> the UI is responsive again. Don't know if this is considered slow, but
> to me it feels like it [4].
Yeah sure it is. It is too slow to me. I hope installing the libc6-dbg
package helps.
>
> Apart from that I noticed a couple of other points:
> 1. Figuring out the current line and where break points are is somewhat
> difficult in the current version (small symbols in the left gutter). A
> better or complimentary solution (IMHO) would be to highlight the
> current line with the selection colour and the breakpoint lines with
> <urgent highlight colour>.
Yeah, that can be done.
> 2. It's difficult to tell when the project is running and when it's
> broken in (at a glance). Point 1 would help with this, but maybe adding
> a status <bar/toolbar item/something else> with the current status
> ("running", "broken in at break point","broken in due to SEGV"...).
Yeah, I other people have raised the status bar request as well. I think we
should add that for the next release to come. Not 0.5, but the one after
that.
> 3. Sometimes gdb compiles out symbols. The first time I encountered
> this, I thought Nemiver / gdb was broken as it couldn't find the symbol
> and wouldn't put any tool-tip up with the value. It'd be nice to put a
> tool-tip like "Symbol not available" up when hovering.
Well, it is not gdb that compiles out the symbols, but your compiler, most
likely because you did compile the code with optimisation on. Given the GDB
interface that we have today, it is not trivial to detect
(in a portable way) if one symbol in particular has debugging symbols or
not. But I agree with you that this feature could be very interesting to
have.
>
> Anyway, Nemiver rocks. Thanks for working on it, and keep it up. It's
> definitely made my life in GNOME easier and more fun.
Thank you for your useful feedback.
Cheerio,
Dodji.
--
Dodji Seketeli
http://www.seketeli.org/dodji
[
Date Prev][Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]