This time I've gotten what looks like useful information: by typing
fin, and then hitting the return key a bunch of times, it became
clear that Emacs was doing a lot of garbage collection -- and a number
of the calls to mark_object took a good chunk of a second to finish
(gdb) Run till exit from #0 interrupt_signal (signalnum=2) at
keyboard.c:10390
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0xe420: Input/output error.
(gdb) Run till exit from #0 interrupt_signal (signalnum=2) at
* Emacs uses 100% of the CPU for about two minutes. This seems
bugaceous; normally Emacs can visit a file of this size with no
perceptible delay.
Please use GDB to find out what it's doing. Guessing such things is
not an efficient method.
Next step: use the `finish' command repeatedly, to see which of these
frames return quickly, and which ones run a long time.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Richard == Richard Stallman [EMAIL PROTECTED] writes:
Richard Next step: use the `finish' command repeatedly, to see
Richard which of these frames return quickly, and which ones run
Richard a long time.
Hmm, that doesn't work --
(gdb) fin
Run till exit from #0 0xe410
I started with a rather large file (attached) that I generated with a
program; I think it contains every possible unicode character, UTF-8
encoded, in order from 0 through 0x10 inclusive.
I generated the file with this program for PLT scheme version 350:
(let loop ((chars-considered
* If I hit C-n C-n, Emacs again starts using 100% of the CPU, for
perhaps 5 seconds
IIUC correctly, the file has some majorly long lines, so it's no wonder C-n
takes a long time.
Stefan
___
emacs-pretest-bug mailing list
Stefan == Stefan Monnier [EMAIL PROTECTED] writes:
* If I hit C-n C-n, Emacs again starts using 100% of the CPU,
for perhaps 5 seconds
Stefan IIUC correctly, the file has some majorly long lines, so
Stefan it's no wonder C-n takes a long time.
Indeed it does. But it seems
