A similar command for Emacs gives 375, so, ..err yes, that does sound rather
> > There are several factors that might make this slow:
> > 1) An executable that was created from a large number of files.
> address@hidden >find . \( -name \*.cpp -o -name \*.h \) | wc -l
> Would this qualify as "large" ? ;)
large.In GDB, once execution has started, e.g., after hitting a breakpoint, do
> > 2) Using stabs debug format.
> Hmm, not sure. I just compiled with gcc-2.95 (yes, that old....) and "-g".
> "info gcc" gives me the impression that this means stabs or gdb ...
(gdb) info source
Current source file is myprog.c
Compilation directory is /home/nickrob
Located in /home/nickrob/myprog.c
Contains 262 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Includes preprocessor macro info.
Stabs is an old debug format and I suspect it might be the default for gcc-2.95.
Maybe you can compile with DWARF 2 instead (using `-gdwarf-2') then Emacs should
start up more qickly.
By old, I guess I mean 100MHz. It looks like it might not be CPU bound,
> > 3) Using an old PC.
> address@hidden >cat /proc/cpuinfo
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Pentium(R) 4 CPU 2.40GHz
> cpu MHz : 2405.535
> cache size : 512 KB
> Not that old...
> CPU is at 20% while "initialising....".
> /home is mounted via nfs but I can hardly see any network activity while
I think that has the same effect as my patch would, i.e., just not build the
> > If this is the problem I can post a patch that might speed things up but
> I would try this :)
> > just turning off gud-tooltip-mode might help.
> "gud-tooltip-mode is a variable defined in `gud.el'.
> Its value is nil"
> So it is turned off.
> Many thanks for your help :) For the time beeing, I'll just load the
> binary from within gdb. Everything seems to work and I don't have to wait
> 1:30 minutes. If my colleages see this, I will have to hear their laughter
> till the end of days ;)
list. It just means that initially you need to set breakpoints, etc, from the
All these tasks that Emacs performs behind the users back should be benchmarked
and optimised really, but I just haven't found the time.