--- Begin Message ---
|
Subject: |
27.0.50; Massive GC when shift-selecting text in HELLO |
|
Date: |
Fri, 31 May 2019 22:47:05 +0300 |
To reproduce:
emacs -Q
C-h h
C-SPC
C-f C-f C-f ....
You will see a ~0.5 sec delay after each C-f, before its effect of
extending the region is visible. The reason is GC after every
keystroke, and it seems to be caused by the changes in commit 479f51a.
That commit caused mode-line-default-help-echo to be called each time
Emacs needs to redisplay the mode line, and that seems to produce lots
of garbage, at least with the HELLO file.
If this function cannot be optimized to produce less garbage, could we
perhaps somehow cache the value of the help-echo and not recalculate
it unless something really changed?
In GNU Emacs 27.0.50 (build 1021, i686-pc-mingw32)
of 2019-05-31 built on HOME-C4E4A596F7
Repository revision: 40bc7ddb7529e516e380cc2f2d904feb3faadced
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure -C --prefix=/d/usr --with-wide-int --with-modules
--enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: ENU
locale-coding-system: cp1255
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
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
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
elec-pair mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 threads w32notify w32 lcms2 multi-tty make-network-process
emacs)
Memory information:
((conses 16 50602 9597)
(symbols 48 7062 1)
(strings 16 18354 2121)
(string-bytes 1 521183)
(vectors 16 9578)
(vector-slots 8 119896 9488)
(floats 8 19 220)
(intervals 40 257 97)
(buffers 880 11))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#36032: 27.0.50; Massive GC when shift-selecting text in HELLO |
|
Date: |
Sat, 01 Jun 2019 18:54:24 +0300 |
> Cc: address@hidden
> From: martin rudalics <address@hidden>
> Date: Sat, 1 Jun 2019 16:01:42 +0200
>
> > But neither the 17 first GCs nor the 18th one cause any tangible
> > delays in response to C-f.
>
> Interesting. Here the release branch is just as slow as master.
> Visiting HELLO takes about 50 seconds and one shifted C-f about one
> second (or one GC cycle) regardless of where in the buffer I am.
> Moreover, -O0 and -O3 builds incur about the same delays.
OK, I installed the fix on the release branch. Thanks.
--- End Message ---