GNU bug report logs - #9589
23.1; Excessive CPU consumption for VERY long lines

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9589 in the body.
You can then email your comments to 9589 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Ludwig, Mark" <ludwig.mark <at> siemens.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 23.1; Excessive CPU consumption for VERY long lines
Date: Sat, 24 Sep 2011 01:13:25 +0000

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The information below (about the instance of Emacs in which I started this bug report) is irrelevant, because the problem was not exercised in this instance of Emacs, but I have left it, lest I be accused of not supplying the standard text.

The problem context is a text file with one or more extremely long lines.  For example, you may use C-u 8 0 0 0 0 0 . (to get 800,000 "." characters).  Do this in the middle of an otherwise normal text file that fills several screens, so that starting at beginning of the buffer you may issue C-v at least once before the long line becomes visible, and similarly have sufficient shorter lines at the end of the buffer so that you may issue M-v at least once before the long line becomes visible.  The problem is that some commands work very slowly when this long line is visible (in the case of C-v, M-v and C-l) while others are quick.  Once point is positioned in the long line, I found that the quick commands include C-a, M-b, M-<, and M->.  Slow commands include C-e, M-f, C-p, and C-n.  I did not try to go through all of the movement commands to sniff out which are quick and which are slow.  On my machine, quick is instantaneous, while slow takes up to 7 seconds to respond.  The slowness seems to vary with the column of point (larger column number reported from C-x =).  Starting at the beginning of the long line, several C-v commands are quick, but they slow down as point moves further into the long line.  The slowest position is the end of the line, where C-v and M-v take the most time.

I did not attempt to measure the performance with longer or shorter lines, but I imagine the slowness (for the slow commands) is linear with the length of the line.  I leave that experimentation to you.

Thanks.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
c:/Apps/emacs-23.1/etc/DEBUG for instructions.


In GNU Emacs 23.1.1 (i386-mingw-nt6.1.7600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 6.1.7600
configured using `configure --with-gcc (4.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  display-time-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-l C-n C-n C-n C-n C-n C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-SPC C-n 
C-n C-n C-n C-w C-x C-s C-z <switch-frame> C-v <switch-frame> 
C-p C-p C-p C-p C-p C-l C-n C-n C-SPC C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-w C-x C-s C-SPC C-p C-p C-p 
C-p C-p C-p C-p C-w C-l C-SPC C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-w C-l C-x C-s C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-SPC C-n C-n C-w C-l C-p C-p C-p C-p C-p C-SPC 
C-n C-n C-n C-w C-k C-k C-k C-k C-k C-k C-p C-p C-p 
C-p C-p C-l C-x C-s C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-k C-k C-k C-k C-k 
C-k C-x C-s C-x C-o C-x C-s M-r M-v C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-SPC C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-w C-x C-o C-l C-SPC C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-w 
C-l C-x C-s C-l C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-l M-v M-v M-v M-r C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-l C-p C-l C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-l <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
Saving file d:/mrl/Today.txt...
Wrote d:/mrl/Today.txt
Saving file d:/mrl/Today.txt...
Wrote d:/mrl/Today.txt
Saving file d:/mrl/Today.txt...
Wrote d:/mrl/Today.txt
Mark set
Mark activated
Saving file d:/mrl/Today.txt...
Wrote d:/mrl/Today.txt

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.