GNU bug report logs - #6964
23.2; revert-buffer takes 60 times longer than initial read

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 6964 in the body.
You can then email your comments to 6964 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: "Daniel B." <dsb <at> smart.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; revert-buffer takes 60 times longer than initial read
Date: Wed, 01 Sep 2010 11:01:41 -0400

Reverting a file (executing revert-buffer) takes much (e.g., 60 times)
longer than reading the file initially.

For a 30MB file that originally took about 3 seconds to load, executing
revert-buffer took 179 seconds.




In GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600)
 of 2010-05-08 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/xpm/include'

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: Fundamental

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

Recent input:
s <return> C-y <return> y e s <return> x b l o <tab>
C-g C-x b l <backspace> L o <tab> <return> <escape>
x t a g s <backspace> <backspace> <backspace> <backspace>
v i s <tab> i <tab> t <tab> <return> <return> y e s
<return> y C-n <escape> x r e p e <tab> - m a <return>
s e a <return> y <return> <escape> x s h e l l <return>
C-r > A G S C-e <return> <escape> x r e p e <tab> m
a <backspace> <backspace> - a <backspace> m a <return>
s e a <return> y <return> y e s <return> <help-echo>
<help-echo> C-x 2 C-x C-g C-x b * c <tab> <return>
<escape> > <S-escape> < C-s < < C-n C-s 3 d C-s C-s
C-s C-s C-n C-x o <escape> , <escape> , <escape> ,
<escape> , M-b M-b M-b M-b C-SPC C-e <escape> w <escape>
x t a g s <return> q u e <return> C-y <return> C-y
C-a M-f C-f " I C-d C-d M-f M-f M-f M-f M-f M-b y e
C-d C-d C-e M-b f l C-d C-d <return> C-p <escape> ,
<escape> < <escape> , y C-g <escape> x r e v e r t
<return> y e s <return> <escape> < <escape> , <help-echo>
<help-echo> <help-echo> C-n C-p C-x C-f . <return>
C-x o C-x b <return> C-x o C-s x m l - s c h C-a C-e
f y e s <return> C-x b <return> C-x o C-x k <return>
f y <help-echo> C-x o C-g C-x o C-x k <return> f y
f y <escape> x r e v e t <backspace> r t <return> y
e s <return> <help-echo> <help-echo> <help-echo> <help-echo>
<escape> x r e p o <tab> r <tab> <return>

Recent messages:
Quit [2 times]
Mark set [2 times]
Mark saved where search started
Quit
File L-w3c-xml-schema-comments is large (29MB), really open? (y or n)
Quit
File L-w3c-xml-schema-comments is large (29MB), really open? (y or n)
Quit
File L-w3c-xml-schema-comments is large (29MB), really open? (y or n)
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug dired-aux apropos help-mode view
sh-script executable chistory ansi-color shell mule-util cc-mode
cc-fonts cc-menus cc-cmds etags multi-isearch parse-time vc-cvs
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
easymenu nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc
xmltok compile comint ring dired cc-styles cc-align cc-engine cc-vars
cc-defs regexp-opt tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process multi-tty
emacs)


Daniel

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Daniel B." <dsb <at> smart.net>
Cc: 6964 <at> debbugs.gnu.org
Subject: Re: bug#6964: 23.2; revert-buffer takes 60 times longer than
 initial read
Date: Wed, 21 Aug 2019 15:30:58 -0700

"Daniel B." <dsb <at> smart.net> writes:

> Reverting a file (executing revert-buffer) takes much (e.g., 60 times)
> longer than reading the file initially.
>
> For a 30MB file that originally took about 3 seconds to load, executing
> revert-buffer took 179 seconds.

(I'm going through old bug reports that have unfortunately gotten no
attention yet.)

I tried reproducing this with a 200MB binary file.  Reading it initially
took less than a second, and saying `M-x revert-buffer' seemed to take
about the same time.

Are you still seeing this problem, and if so, what kind of data do you
have in the buffer when it takes this long?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Daniel B." <dsb <at> smart.net>
Cc: 6964 <at> debbugs.gnu.org
Subject: Re: bug#6964: 23.2; revert-buffer takes 60 times longer than
 initial read
Date: Mon, 14 Oct 2019 07:59:38 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I tried reproducing this with a 200MB binary file.  Reading it initially
> took less than a second, and saying `M-x revert-buffer' seemed to take
> about the same time.
>
> Are you still seeing this problem, and if so, what kind of data do you
> have in the buffer when it takes this long?

More information was requested some weeks back, but no response was
given, so I'm closing this bug report.  If you're still seeing this
problem, please reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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