IDB Debuger unusable slow

[ulukaigmx_de]

Hello im using the Intel debuger idb - or at least I'm trying.
The (eclipse like) interfave is really slow, e.g. right click, and then i have to wait 5 sec for the menu.
Compilong was like that:
ifort -o "mom44" -g mom44.f momo_shared_code44.f
Thats my version:
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.184]
I just think it's not supposed to be like that...
Im running SUSE 11.1 Linux.
I'm thinking, is there a good way to use emacs and idb? cause there is no syntax highliting in the idb eclipese like editor.
Thanky for any help,
Andre

[geha]

Quoting - ulukaigmx.de

Hello im using the Intel debuger idb - or at least I'm trying.
The (eclipse like) interfave is really slow, e.g. right click, and then i have to wait 5 sec for the menu.
Compilong was like that:
ifort -o "mom44" -g mom44.f momo_shared_code44.f
Thats my version:
Intel Debugger for applications running on Intel 64, Version 11.1, Build [1.2097.2.184]
I just think it's not supposed to be like that...
Im running SUSE 11.1 Linux.
I'm thinking, is there a good way to use emacs and idb? cause there is no syntax highliting in the idb eclipese like editor.
Thanky for any help,
Andre

Hello,
I would like to confirm this observation. The graphical idb interface (Version 11.1, Ubuntu 8.10) is in such a way slow that it can not really be used. Therefore I'm still using ifort 11.0 although the "Locals"-window doesn't work correctly.

It is possible to run emacs and idb. There you have to run M-x gdb and then change the command to "idb -fullname ". Unfortunately it is not possible to use the option --annotate=3 which make emacs to something like an IDE. BTW, gdb is not compatible to ifort.

Regards,
Georg

[Rob_Mueller-Albrecht]

Hi all,

in everyday debugging with regular stepping and breakpoints the IDB performance should actually be fairly smooth - if not I would need detailed testcases to reproduce the performance issues.

That said, there are one or two things we are aware of. When populating the source file list we are currently doing too agressive source caching, which at least on first connect and symbol info load can slow things down considerably.

Similarly when the local variables window is open and contains huge data structures updating the contents of these data structures can take a moment.

The first of these issues is currently already addressed and should make it into one of our next releases. The second issue is currently already fixed in another related debugger product and should also be fixedfairly soon.

Both of theseproblems should only show up with really large applications. They are not really GUI specific, but can become more obvious when usingthe GUI because of the display window updates for the symbols.

[Rob_Mueller-Albrecht]

One more question: Are you using IDB natively or are you using it over a network connection? What does you r network setup look like if you do?

Thanks, Rob

[geha]

Quoting - Robert MuellerAlbrecht (Intel)

One more question: Are you using IDB natively or are you using it over a network connection? What does you r network setup look like if you do?

Thanks, Rob

I'm using it natively. In my experience, the idb-gui slows down considerably if the locals window is open - also if there are just a view variables. The next really slow event is opening a new file such as a fortran-modul.

Regards,
Georg