--- Begin Message ---
|
Subject: |
25.1; overlays may make emacs very slow |
|
Date: |
Sat, 11 Mar 2017 01:25:22 +0900 |
Evaluating the form below in the *scratch* buffer,
it takes a few seconds to show the result.
(let ((n 65536))
(save-excursion (dotimes (i n) (insert (format "%d\n" i))))
(dotimes (i n) (make-overlay (point) (progn (forward-line) (point))))
(message "Done."))
If I evaluate the form as below, it takes about 30 seconds.
(1) switch to a newly created buffer
(2) insert the code into the buffer
(3) insert 2 line breaks after the last closing parenthesis
(4) type C-x C-e
If I evaluate the form as below, it takes about 10 minutes.
(1) switch to a newly created buffer
(2) type M-: and input the code
In each case, the message "Done." is displayed in a few seconds.
But it takes a long time to display the buffer contents.
In GNU Emacs 25.1.1 (i686-w64-mingw32)
of 2016-09-18 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.0.6002
Configured using:
'configure --host=i686-w64-mingw32 --without-dbus
--without-compress-install CFLAGS=-static'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: JPN
locale-coding-system: cp932
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-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-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)
Memory information:
((conses 8 91638 4868)
(symbols 32 19658 0)
(miscs 32 50 119)
(strings 16 15828 4143)
(string-bytes 1 427112)
(vectors 8 13127)
(vector-slots 4 519096 5994)
(floats 8 164 67)
(intervals 28 213 16)
(buffers 520 19))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#2963: wishlist: improve speed of `make-overlay' |
|
Date: |
Sat, 21 Oct 2023 04:52:15 -0700 |
Eli Zaretskii <eliz@gnu.org> writes:
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, wl@gnu.org,
>> Stefan Monnier <monnier@iro.umontreal.ca>, politza@hochschule-trier.de
>> Date: Sat, 21 Oct 2023 08:33:34 -0300
>> From: Mauro Aranda <maurooaranda@gmail.com>
>>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> > Werner LEMBERG <wl@gnu.org> writes:
>> >
>> >> The complexity of `make-overlay' appears to be O(N), which makes it
>> >> unbearably slow for larger buffers.
>> >
>> > Andreas did a lot of work on reimplementing the overlay internals a few
>> > years back -- but I see that it was never merged?
>> >
>> > Andreas, what's the state of the feature/noverlay branch?
>>
>> This message was 2 years ago. Meanwhile the feature/noverlay branch got
>> merged. Maybe this can be closed. CCing Stefan M.
>
> I think it should be closed, indeed.
Yup, done.
--- End Message ---