GNU bug report logs -
#18522
occasional slow performance in some Gnus code
Previous Next
Reported by: Peter Münster <pmlists <at> free.fr>
Date: Mon, 22 Sep 2014 10:38:02 UTC
Severity: normal
Tags: fixed
Found in version 24.4.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18522 in the body.
You can then email your comments to 18522 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18522; Package
emacs.
(Mon, 22 Sep 2014 10:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Peter Münster <pmlists <at> free.fr>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 22 Sep 2014 10:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
ELP shows, that the mapcar function called from gnus-thread-latest-date
takes a lot of time (uptime of emacs is several days):
function calls total time [s] time per call [s]
-----------------------------------------------------------------------
mapcar 20250 5.3743043500 0.0002653977
After restarting emacs:
mapcar 21468 0.1387124370 6.461...e-06
About 40 times faster now!!
Thanks in advance for any help or hints how to debug further,
Further details:
In GNU Emacs 24.4.50.1 (x86_64-suse-linux-gnu, GTK+ Version 3.10.9)
of 2014-09-14 on micropit
Repository revision: 117880 michael.albinus <at> gmx.de-20140914090011-2k4yr2tapso2uoz6
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description: openSUSE 13.1 (Bottle) (x86_64)
Configured using:
`configure --without-toolkit-scroll-bars'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
Important settings:
value of $LC_ALL: en_GB.utf8
value of $LC_CTYPE: en_GB.utf8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Group
Minor modes in effect:
gnus-undo-mode: t
pm/keys-minor-mode: t
savehist-mode: t
show-paren-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
column-number-mode: t
line-number-mode: t
Features:
(shadow emacsbug mule-util mm-archive gnus-dup org-colview elp misearch
multi-isearch mailalias bbdb-message vc-dispatcher vc-svn org-rmail
org-mhe org-irc org-info org-gnus org-docview org-bibtex bibtex org-bbdb
org-w3m sort smiley gnus-cite mail-extr gnus-async gnus-bcklg qp
gnus-salt gnus-ml disp-table bbdb-gnus bbdb-mua bbdb-com crm gnus-delay
gnus-draft nndraft nnmh nnml gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-cache gnus-demon nntp gnus-icalendar org-capture
gnus-art mm-uu mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
icalendar diary-lib diary-loaddefs json jl-encrypt epg mml2015
epg-config gnus-start gnus-cloud nnimap nnmail mail-source tls utf7
netrc nnoo parse-time gnus-spec gnus-int gnus-range message sendmail
dired rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems gnus-compat url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source eieio eieio-core password-cache url-vars mailcap nnheader
gnus-util mail-utils mm-util mail-prsvr wid-edit notifications dbus xml
wombat-theme savehist paren delsel server org-clock bbdb bbdb-site
timezone lua-mode edmacro kmacro rx org-notify org-element org byte-opt
bytecomp byte-compile cconv advice help-fns org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob
ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs
slime-autoloads cl-macs bbdb-loaddefs tex-site auto-loads gnus-load cl
gv autoinsert compile comint ansi-color po-mode php-mode derived etags
ring cc-langs cl-loaddefs cl-lib cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs speedbar sb-image
ezimage dframe easymenu time-date tooltip electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar 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 minibuffer 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 make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 344956 38663)
(symbols 48 43128 62)
(miscs 40 123 587)
(strings 32 96718 17145)
(string-bytes 1 3253927)
(vectors 16 43741)
(vector-slots 8 1564631 71072)
(floats 8 335 1543)
(intervals 56 2324 486)
(buffers 976 21)
(heap 1024 66555 4558))
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18522; Package
emacs.
(Mon, 22 Sep 2014 10:44:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Hi,
Here is a thread about this issue:
http://thread.gmane.org/gmane.emacs.gnus.general/84605
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18522; Package
emacs.
(Mon, 22 Sep 2014 12:50:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> ELP shows, that the mapcar function called from gnus-thread-latest-date
> takes a lot of time (uptime of emacs is several days):
This is the wrong measurement: it just means that some calls to mapcar
spend a lot of time in the corresponding loop, but the
time for mapcar includes the time spent in the function passed to
mapcar, which is where most of the time is likely spent anyway.
Could you use the native, sampling, profiler instead of ELP?
- M-x profiler-start RET RET
- ... reproduce the slow operation ...
- M-x profiler-report RET
- C-u RET on the first entry to unfold it
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18522; Package
emacs.
(Mon, 22 Sep 2014 13:49:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Mon, Sep 22 2014, Stefan Monnier wrote:
> the time for mapcar includes the time spent in the function passed to
> mapcar, which is where most of the time is likely spent anyway.
Yes. The function is:
(lambda (header) (gnus-float-time
(gnus-date-get-time
(mail-header-date header))))
I've checked all 3 functions (gnus-float-time, gnus-date-get-time and
mail-header-date) with ELP, but emacs did not spend any significant time
in these 3 functions...
> Could you use the native, sampling, profiler instead of ELP?
>
> - M-x profiler-start RET RET
> - ... reproduce the slow operation ...
> - M-x profiler-report RET
> - C-u RET on the first entry to unfold it
Yes. I'll do that in some days, when mapcar becomes slow again.
--
Peter
Changed bug title to 'occasional slow performance in some Gnus code' from '24.4.50; mapcar is very slow'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 23 Sep 2014 09:49:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Sep 2014 21:37:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 18522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Sep 22 2014, Peter Münster wrote:
>> Could you use the native, sampling, profiler instead of ELP?
>>
>> - M-x profiler-start RET RET
>> - ... reproduce the slow operation ...
>> - M-x profiler-report RET
>> - C-u RET on the first entry to unfold it
>
> Yes. I'll do that in some days, when mapcar becomes slow again.
Hi,
Please find attached 2 files with profiler-reports when entering a Gnus
group:
- profiler-slow.txt: entering a group is slow, and emacs was uptime since
about 3 days
- profiler-fast.txt: entering the same group after a fresh restart of emacs
--
Peter
[profiler-slow.txt (text/plain, attachment)]
[profiler-fast.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Sep 2014 06:58:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Date: Thu, 25 Sep 2014 23:36:36 +0200
> Cc: 18522 <at> debbugs.gnu.org
>
> Please find attached 2 files with profiler-reports when entering a Gnus
> group:
> - profiler-slow.txt: entering a group is slow, and emacs was uptime since
> about 3 days
> - profiler-fast.txt: entering the same group after a fresh restart of emacs
Is that for the same input? How come command-execute was called 2464
times in the first profile, and only 303 times in the second? This
alone can explain an 8-fold slowdown.
Sorry if this is a silly question: I don't use Gnus. But to compare 2
profiles, you need to create each one of them when Emacs does the same
job in each time. Otherwise, there's a factor at work that we cannot
glean from the profile alone.
Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
both cases, which is above the mapcar part. Below mapcar, the most
expensive part is parse-time-string, which doesn't really surprise me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Sep 2014 07:16:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 26 2014, Eli Zaretskii wrote:
>> Please find attached 2 files with profiler-reports when entering a Gnus
>> group:
>> - profiler-slow.txt: entering a group is slow, and emacs was uptime since
>> about 3 days
>> - profiler-fast.txt: entering the same group after a fresh restart of emacs
>
> Is that for the same input?
Yes. In both cases I call gnus-group-select-group for the same group.
> How come command-execute was called 2464 times in the first profile,
> and only 303 times in the second? This alone can explain an 8-fold
> slowdown.
Sorry, I forgot to label the columns: 303 and 2464 are "CPU samples".
> Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
> both cases, which is above the mapcar part. Below mapcar, the most
> expensive part is parse-time-string, which doesn't really surprise me.
On line 16, the slow mapcar takes 1090 CPU samples and the fast one 64.
Below line 16, the profiler outputs are different and I don't know why
and how to debug further...
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Sep 2014 07:37:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: monnier <at> iro.umontreal.ca, 18522 <at> debbugs.gnu.org
> Date: Fri, 26 Sep 2014 09:15:01 +0200
>
> > How come command-execute was called 2464 times in the first profile,
> > and only 303 times in the second? This alone can explain an 8-fold
> > slowdown.
>
> Sorry, I forgot to label the columns: 303 and 2464 are "CPU samples".
No, it's me that needs to be sorry: I keep forgetting that.
> > Anyway, looks like gnus-summary-read-group-1 takes a lot of CPU in
> > both cases, which is above the mapcar part. Below mapcar, the most
> > expensive part is parse-time-string, which doesn't really surprise me.
>
> On line 16, the slow mapcar takes 1090 CPU samples and the fast one 64.
> Below line 16, the profiler outputs are different and I don't know why
> and how to debug further...
I think the conclusion is that parse-time-string takes the blame. To
see what part in parse-time-string is the culprit, perhaps load
parse-time.el (the source) before the experiment, and maybe the
profile will show more useful info.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 01 Oct 2014 19:56:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 26 2014, Eli Zaretskii wrote:
> I think the conclusion is that parse-time-string takes the blame. To
> see what part in parse-time-string is the culprit, perhaps load
> parse-time.el (the source) before the experiment, and maybe the
> profile will show more useful info.
This is the result:
--8<---------------cut here---------------start------------->8---
- command-execute 3228 94%
- call-interactively 3228 94%
- funcall-interactively 3150 92%
- gnus-group-select-group 3142 92%
- gnus-group-read-group 3142 92%
- gnus-summary-read-group 3142 92%
- gnus-summary-read-group-1 3142 92%
- gnus-summary-prepare 2772 81%
- gnus-sort-threads 2657 78%
- byte-code 2657 78%
- gnus-sort-threads-recursive 2657 78%
- sort 2649 77%
- #<compiled 0x16237ad> 2649 77%
- gnus-thread-sort-by-most-recent-date 2648 77%
- gnus-thread-latest-date 2648 77%
- mapcar 2647 77%
- #<compiled 0x8d9233> 2645 77%
- safe-date-to-time 2641 77%
- date-to-time 2641 77%
- byte-code 2641 77%
- parse-time-string 2638 77%
- let 2637 77%
- parse-time-tokenize 2613 76%
- let 2612 76%
- while 2612 76%
- while 2605 76%
- and 2602 76%
- setq 1719 50%
- parse-time-string-chars 1712 50%
- save-match-data 1697 49%
- let 1689 49%
- unwind-protect 1680 49%
- progn 1675 49%
- let 26 0%
- cond 19 0%
string-match 1 0%
- not 876 25%
- setq 875 25%
- parse-time-string-chars 874 25%
- save-match-data 870 25%
- let 868 25%
- unwind-protect 865 25%
- progn 861 25%
- let 22 0%
- cond 22 0%
- string-match 4 0%
setq 4 0%
set-match-data 1 0%
- < 2 0%
setq 1 0%
setq 1 0%
- if 4 0%
- setq 4 0%
- cons 2 0%
- if 2 0%
- parse-integer 1 0%
- let 1 0%
- if 1 0%
- progn 1 0%
let 1 0%
- while 24 0%
- let 24 0%
- while 23 0%
- let* 20 0%
- if 13 0%
- progn 7 0%
- while 6 0%
- let 6 0%
- if 6 0%
- let 6 0%
- if 5 0%
- parse-integer 5 0%
- let 4 0%
- if 4 0%
- progn 3 0%
- let 3 0%
- while 1 0%
and 1 0%
if 1 0%
- car-safe 1 0%
- prog1 1 0%
setq 1 0%
- and 6 0%
- setq 5 0%
- cond 5 0%
- and 2 0%
- not 1 0%
eq 1 0%
<= 1 0%
cdr 1 0%
funcall 1 0%
- car-safe 6 0%
- prog1 3 0%
setq 2 0%
and 1 0%
car-safe 1 0%
apply 3 0%
- message-flatten-list 1 0%
apply 1 0%
- mapcar 7 0%
- #<compiled 0x8d7e39> 7 0%
- gnus-sort-subthreads-recursive 7 0%
- mapcar 4 0%
- #<compiled 0x8d8185> 4 0%
- gnus-sort-subthreads-recursive 4 0%
- mapcar 4 0%
- #<compiled 0x8d8185> 3 0%
- gnus-sort-subthreads-recursive 3 0%
- sort 3 0%
- #<compiled 0x16237ad> 3 0%
- gnus-thread-sort-by-most-recent-date 3 0%
- gnus-thread-latest-date 3 0%
- mapcar 3 0%
- #<compiled 0x8d9233> 3 0%
- safe-date-to-time 3 0%
- date-to-time 3 0%
- byte-code 3 0%
- parse-time-string 2 0%
- let 2 0%
- parse-time-tokenize 2 0%
- let 2 0%
- while 2 0%
while 1 0%
apply 1 0%
- sort 3 0%
- #<compiled 0x16237ad> 3 0%
- gnus-thread-sort-by-most-recent-date 3 0%
- gnus-thread-latest-date 3 0%
- mapcar 3 0%
- #<compiled 0x8d9233> 3 0%
- safe-date-to-time 3 0%
- date-to-time 3 0%
- byte-code 3 0%
apply 2 0%
- parse-time-string 1 0%
- let 1 0%
- while 1 0%
- let 1 0%
while 1 0%
- gnus-summary-prepare-threads 97 2%
- eval 88 2%
- let 88 2%
- gnus-add-text-properties 85 2%
- progn 84 2%
- insert 82 2%
- format 80 2%
- let* 54 1%
- eval 54 1%
- let 54 1%
- eval 51 1%
- gnus-summary-from-or-to-or-newsgroups 50 1%
- mail-decode-encoded-address-string 49 1%
- rfc2047-decode-string 35 1%
- rfc2047-decode-encoded-words 16 0%
- byte-code 16 0%
- quoted-printable-decode-string 16 0%
generate-new-buffer 5 0%
- byte-code 3 0%
- kill-buffer 1 0%
- replace-buffer-in-windows 1 0%
unrecord-window-buffer 1 0%
mm-disable-multibyte 2 0%
quoted-printable-decode-region 1 0%
generate-new-buffer 7 0%
- byte-code 6 0%
kill-buffer 4 0%
rfc2047-strip-backslashes-in-quoted-strings 2 0%
bidi-string-mark-left-to-right 1 0%
- if 2 0%
if 1 0%
> 1 0%
- gnus-user-date 23 0%
- byte-code 21 0%
- eval 17 0%
gnus-seconds-year 8 0%
gnus-seconds-today 6 0%
- + 2 0%
gnus-seconds-today 1 0%
gnus-summary-line-message-size 3 0%
- cons 1 0%
cons 1 0%
- gnus-summary-highlight-line 3 0%
gnus-put-text-property-excluding-characters-with-faces 1 0%
- gnus-gather-threads-by-references 9 0%
- mail-header-remove-comments 8 0%
- byte-code 5 0%
- kill-buffer 2 0%
- replace-buffer-in-windows 1 0%
unrecord-window-buffer 1 0%
generate-new-buffer 3 0%
- gnus-make-threads 1 0%
- mapatoms 1 0%
- #<compiled 0x8d6107> 1 0%
- mapcar 1 0%
#<compiled 0x8d60e3> 1 0%
- gnus-select-newsgroup 366 10%
- gnus-fetch-headers 363 10%
- gnus-get-newsgroup-headers-xover 362 10%
- byte-code 354 10%
- byte-code 292 8%
- mail-decode-encoded-address-string 203 5%
- rfc2047-decode-string 141 4%
- rfc2047-decode-encoded-words 105 3%
- byte-code 97 2%
- quoted-printable-decode-string 86 2%
generate-new-buffer 19 0%
- byte-code 19 0%
- kill-buffer 2 0%
replace-buffer-in-windows 1 0%
mm-disable-multibyte 16 0%
quoted-printable-decode-region 1 0%
- rfc2047-charset-to-coding-system 7 0%
- mm-charset-to-coding-system 3 0%
mm-coding-system-p 2 0%
generate-new-buffer 16 0%
- byte-code 13 0%
- kill-buffer 4 0%
- replace-buffer-in-windows 2 0%
unrecord-window-buffer 2 0%
- rfc2047-strip-backslashes-in-quoted-strings 2 0%
- byte-code 2 0%
forward-sexp 2 0%
- mail-decode-encoded-word-string 58 1%
- rfc2047-decode-encoded-words 44 1%
- byte-code 43 1%
- quoted-printable-decode-string 40 1%
mm-disable-multibyte 7 0%
- byte-code 5 0%
- kill-buffer 1 0%
replace-buffer-in-windows 1 0%
generate-new-buffer 4 0%
- byte-code 7 0%
- kill-buffer 1 0%
- replace-buffer-in-windows 1 0%
unrecord-window-buffer 1 0%
generate-new-buffer 2 0%
- mail-header-remove-comments 33 0%
generate-new-buffer 21 0%
- byte-code 12 0%
- kill-buffer 4 0%
- replace-buffer-in-windows 2 0%
unrecord-window-buffer 1 0%
- gnus-retrieve-headers 1 0%
- gnus-cache-retrieve-headers 1 0%
- gnus-retrieve-headers 1 0%
- nnml-retrieve-headers 1 0%
- nnml-retrieve-headers-with-nov 1 0%
- nnheader-insert-file-contents 1 0%
mm-insert-file-contents 1 0%
- gnus-summary-setup-default-charset 1 0%
gnus-parameter-charset 1 0%
- gnus-article-setup-buffer 1 0%
gnus-get-buffer-create 1 0%
- gnus-group-decoded-name 1 0%
gnus-group-name-decode 1 0%
- gnus-summary-setup-buffer 1 0%
- gnus-summary-mode 1 0%
- gnus-update-summary-mark-positions 1 0%
gnus-summary-insert-line 1 0%
- gnus-run-hooks 1 0%
- apply 1 0%
- run-hooks 1 0%
- gnus-apply-kill-file 1 0%
gnus-newsgroup-kill-file 1 0%
- execute-extended-command 8 0%
- command-execute 6 0%
- call-interactively 6 0%
- funcall-interactively 6 0%
- profiler-report 6 0%
- profiler-report-cpu 6 0%
profiler-cpu-profile 6 0%
- byte-code 78 2%
- read-extended-command 78 2%
- completing-read 78 2%
- completing-read-default 78 2%
- read-from-minibuffer 66 1%
- redisplay_internal (C function) 1 0%
menu-bar-update-buffers 1 0%
- timer-event-handler 1 0%
- timer-activate-when-idle 1 0%
- timer--activate 1 0%
timer--time-less-p 1 0%
+ ... 167 4%
+ timer-event-handler 6 0%
redisplay_internal (C function) 1 0%
--8<---------------cut here---------------end--------------->8---
Is "progn" the problem?
What do you think?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 01 Oct 2014 19:59:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I think the conclusion is that parse-time-string takes the blame.
http://debbugs.gnu.org/14776
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 01 Oct 2014 20:26:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 18522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 01 2014, Glenn Morris wrote:
> http://debbugs.gnu.org/14776
Thanks. But it does not explain, why it's much faster after restarting
emacs. Please find attached 2 recent profiler reports for comparison.
--
Peter
[profiler-slow3.txt (text/plain, attachment)]
[profiler-fast3.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 13 Feb 2015 08:29:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> Thanks. But it does not explain, why it's much faster after restarting
> emacs. Please find attached 2 recent profiler reports for comparison.
It's kinda puzzling.
Could you `M-x debug-on-entry RET gnus-sort-threads RET' and then save
the value of the `threads' variable when this is slow and when this is
fast.
And then either compare the values to see whether they're really the
same, or post them here for inspection...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 13 Feb 2015 14:40:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 18522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 13 2015, Lars Ingebrigtsen wrote:
> Could you `M-x debug-on-entry RET gnus-sort-threads RET' and then save
> the value of the `threads' variable when this is slow and when this is
> fast.
>
> And then either compare the values to see whether they're really the
> same, or post them here for inspection...
Hi Lars,
They are the same. Please find attached an example.
--
Peter
[gnus-sort-threads-debug.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sat, 14 Feb 2015 04:21:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> They are the same. Please find attached an example.
The backtrace doesn't contain the full info, unfortunately.
After you enter the debugger, can you go to the *scratch* buffer and
`M-: (pp threads (current-buffer)) RET'
Then post the output here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 02 Mar 2015 14:35:03 GMT)
Full text and
rfc822 format available.
Message #49 received at 18522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Feb 14 2015, Lars Ingebrigtsen wrote:
> After you enter the debugger, can you go to the *scratch* buffer and
>
> `M-: (pp threads (current-buffer)) RET'
Hi,
`threads' is not defined then... Instead I've modified
`gnus-sort-threads' to print `threads' into the buffer.
In both cases it's the same. Please find attached an example.
--
Peter
[gnus-sort-threads.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 20 Jul 2015 12:54:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Hi,
Is there anything, that I could do, for further debugging?
Emacs uptime is 17 days, and entering groups is really *very* slow now.
Info from "ps":
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
peter 3508 2.0 4.2 919932 170548 ? Sl Jul03 502:40 emacs --iconic
--
Peter
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 26 Dec 2015 16:09:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 07 Feb 2016 06:32:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> On Sat, Feb 14 2015, Lars Ingebrigtsen wrote:
>
>> After you enter the debugger, can you go to the *scratch* buffer and
>>
>> `M-: (pp threads (current-buffer)) RET'
>
> Hi,
>
> `threads' is not defined then... Instead I've modified
> `gnus-sort-threads' to print `threads' into the buffer.
>
> In both cases it's the same. Please find attached an example.
Hm. That looks totally normal, I think.
So our supposition here is: The time is spent in parse-time-string. The
data it's running on is the same. But after Emacs has run a significant
amount of time, parse-time-string becomes slower.
To test that, does
(benchmark-run 1
(dotimes (i 10000)
(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
run faster in a newly started Emacs than in one that has been running
for a long time?
An alternative explanation might be that you're inadvertently loading an
alternative version of parse-time.el somewhere, and getting an
uncompiled version of the function. What does `C-h f parse-time-string'
say in a slow and a fast Emacs?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 17 Feb 2016 16:01:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 07 2016, Lars Ingebrigtsen wrote:
> So our supposition here is: The time is spent in parse-time-string. The
> data it's running on is the same. But after Emacs has run a significant
> amount of time, parse-time-string becomes slower.
>
> To test that, does
>
> (benchmark-run 1
> (dotimes (i 10000)
> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
>
> run faster in a newly started Emacs than in one that has been running
> for a long time?
Hi Lars,
It becomes slower and slower:
emacs -Q:
(1.901298604 63 0.7084347450000001)
(1.872230076 62 0.6968837490000003)
(1.875635069 62 0.6954687450000001)
emacs:
(1.717632996 14 0.49240735300000005)
(1.709202998 14 0.49144767599999994)
(1.743671899 15 0.5327712409999996)
just after starting Gnus:
(2.388075413 18 1.118860780999999)
(2.317841377 17 1.056383110000001)
(2.372941828 18 1.1168076720000002)
just after starting org-notify:
(2.573931109 19 1.2253276549999992)
(2.605375629 19 1.2394917619999992)
(2.560276964 19 1.2212755360000003)
after 1 day uptime:
(3.744592118 19 1.5007945239999572)
(3.741772863 19 1.5062292100001287)
(3.744434861 19 1.4990475370001377)
after 2 days uptime:
(5.104874753 18 1.5796559729999444)
(5.244741606 20 1.7344523149997713)
(5.166454389 19 1.6512688520001575)
after 3 days uptime:
(7.111809223 17 1.6411146469995401)
(7.200519214 17 1.6629621439999482)
(7.086889831 18 1.7155860500001836)
> An alternative explanation might be that you're inadvertently loading an
> alternative version of parse-time.el somewhere, and getting an
> uncompiled version of the function. What does `C-h f parse-time-string'
> say in a slow and a fast Emacs?
In both cases: parse-time-string is an autoloaded compiled Lisp function in ‘parse-time.el’.
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 05:16:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
>> (benchmark-run 1
>> (dotimes (i 10000)
>> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
>>
>> run faster in a newly started Emacs than in one that has been running
>> for a long time?
>
> Hi Lars,
>
> It becomes slower and slower:
[...]
> after 1 day uptime:
> (3.744592118 19 1.5007945239999572)
> (3.741772863 19 1.5062292100001287)
> (3.744434861 19 1.4990475370001377)
>
> after 2 days uptime:
> (5.104874753 18 1.5796559729999444)
> (5.244741606 20 1.7344523149997713)
> (5.166454389 19 1.6512688520001575)
>
> after 3 days uptime:
> (7.111809223 17 1.6411146469995401)
> (7.200519214 17 1.6629621439999482)
> (7.086889831 18 1.7155860500001836)
Cool! Then at least we've found the culprit. :-)
Now we just have to find out why. Does anybody have any idea? Could
somebody else also try running the benchmark form up there in a newly
started Emacs and one that's been running for a while to see if they can
reproduce this bug?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 08:29:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Fri, Feb 19 2016 at 16:15, Lars Ingebrigtsen wrote:
> Could somebody else also try running the benchmark form up there in a
> newly started Emacs and one that's been running for a while to see if
> they can reproduce this bug?
Reproducible for me, on a fairly old build from master.
GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2015-02-10 on luna
emacs -Q:
(0.486050254 62 0.14596531899999993)
(0.476148629 62 0.14965575099999995)
(0.48096619 62 0.15016140600000039)
(0.475289574 62 0.14931084599999966)
emacs:
(0.756362151 41 0.4092070400000001)
(0.705364164 40 0.36777845200000003)
(0.706183625 41 0.3791851149999994)
(0.709007708 40 0.37037735199999977)
emacs with 38 days uptime, lots of buffers, gnus running, etc:
(33.491108001 3 0.5502189609999277)
(33.388318264 2 0.3723178949999806)
(34.000763018 3 0.5643239880000124)
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 08:40:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 19 Feb 2016 16:15:08 +1100
> Cc: 18522 <at> debbugs.gnu.org
>
> Peter Münster <pmlists <at> free.fr> writes:
>
> >> (benchmark-run 1
> >> (dotimes (i 10000)
> >> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
> >>
> >> run faster in a newly started Emacs than in one that has been running
> >> for a long time?
> >
> > Hi Lars,
> >
> > It becomes slower and slower:
>
> [...]
>
> Cool! Then at least we've found the culprit. :-)
>
> Now we just have to find out why. Does anybody have any idea? Could
> somebody else also try running the benchmark form up there in a newly
> started Emacs and one that's been running for a while to see if they can
> reproduce this bug?
IMO, the benchmark needs to be changed to factor out GC, because the
time a GC takes depends on the number and structure of objects you
have in your session, and that has nothing to do with the issue at
hand.
So a better benchmark is this:
(let ((gc-cons-threshold most-positive-fixnum))
(benchmark-run 1
(dotimes (i 10000)
(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
full-blown session running for 5 days. That's clearly different from
the data presented by Peter (but I don't use Gnus).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 10:07:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So a better benchmark is this:
>
> (let ((gc-cons-threshold most-positive-fixnum))
> (benchmark-run 1
> (dotimes (i 10000)
> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
>
> FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> full-blown session running for 5 days. That's clearly different from
> the data presented by Peter (but I don't use Gnus).
in my 9 days uptime session, I get (18.433154005 0 0.0)
from -Q I get : (7.823626407 0 0.0)
from a fresh emacs session where I forcibly loaded libraries similar to
my 9-days-old one, I get: (8.661741842 0 0.0)
Perhaps I should go back to optimized builds instead... other than that,
it seems that there is indeed a problem with the older session.
--
Nicolas
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 10:13:01 GMT)
Full text and
rfc822 format available.
Message #75 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Fri, Feb 19 2016 at 10:38, Eli Zaretskii wrote:
> So a better benchmark is this:
>
> (let ((gc-cons-threshold most-positive-fixnum))
> (benchmark-run 1
> (dotimes (i 10000)
> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
In my case, the timings are similar to the runs without GC suppression.
emacs -Q:
(0.376852402 0 0.0)
(0.359729575 0 0.0)
(0.351677433 0 0.0)
My 38-day uptime workhorse-emacs:
(33.980759168 0 0.0)
(33.741870707 0 0.0)
(33.947532796 0 0.0)
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 19 Feb 2016 22:47:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> (let ((gc-cons-threshold most-positive-fixnum))
> (benchmark-run 1
> (dotimes (i 10000)
> (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
>
> FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> full-blown session running for 5 days. That's clearly different from
> the data presented by Peter (but I don't use Gnus).
Well, it's almost twice as slow in a five day old Emacs... doesn't that
show that something weird is going on somewhere?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sat, 20 Feb 2016 08:15:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
> Date: Sat, 20 Feb 2016 09:46:23 +1100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > (let ((gc-cons-threshold most-positive-fixnum))
> > (benchmark-run 1
> > (dotimes (i 10000)
> > (parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000"))))
> >
> > FWIW, this takes 1.2 sec in a fresh "emacs -Q", and 2.0 sec in a
> > full-blown session running for 5 days. That's clearly different from
> > the data presented by Peter (but I don't use Gnus).
>
> Well, it's almost twice as slow in a five day old Emacs... doesn't that
> show that something weird is going on somewhere?
2.0 divided by 1.2 is 1.7, not 2. And Peter's data shows a 3.7-fold
slowdown after only 3 days. So the difference is IMO striking.
Nevertheless, profiling parse-time-string on a more fine-grained level
seems the way to go.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sat, 20 Feb 2016 08:34:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 20 2016, Eli Zaretskii wrote:
> 2.0 divided by 1.2 is 1.7, not 2. And Peter's data shows a 3.7-fold
> slowdown after only 3 days. So the difference is IMO striking.
Hi,
It seems, that the slow-down depends on user activity, not really on
uptime. I've 3 running emacs now: one instance that has loaded my
personal configuration, another with "emacs -Q" and my normal emacs
session with user activity. I observe the slow-down only with the
latter.
> Nevertheless, profiling parse-time-string on a more fine-grained level
> seems the way to go.
How please?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sat, 20 Feb 2016 09:52:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 18522 <at> debbugs.gnu.org
> Date: Sat, 20 Feb 2016 09:33:20 +0100
>
> > Nevertheless, profiling parse-time-string on a more fine-grained level
> > seems the way to go.
>
> How please?
I'd start with profiler.el, to profile the Lisp portions of the
function. It's probably best to load the .el file first and profile
that, although this could skew the profile (because the byte-compiled
version behaves differently).
Another possibility is to add calls to float-time to time portions of
parse-time-string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 11:01:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 20 2016, Eli Zaretskii wrote:
> I'd start with profiler.el, to profile the Lisp portions of the
> function. It's probably best to load the .el file first and profile
> that, although this could skew the profile (because the byte-compiled
> version behaves differently).
Here are 2 profiler reports. The first one, where parse-time-string is
very slow:
--8<---------------cut here---------------start------------->8---
- command-execute 8396 93%
- call-interactively 8396 93%
- funcall-interactively 7881 88%
- eval-expression 7848 87%
- eval 7848 87%
- let 7848 87%
- while 7848 87%
- parse-time-string 7840 87%
- let 7836 87%
- parse-time-tokenize 7089 79%
- let 7073 79%
- while 7057 78%
- while 6959 77%
- and 6891 77%
- setq 4445 49%
- parse-time-string-chars 4413 49%
- let 4301 48%
- unwind-protect 4189 46%
- progn 4141 46%
- let 436 4%
- cond 408 4%
- string-match 96 1%
setq 68 0%
set-match-data 4 0%
- not 2338 26%
- setq 2310 25%
- parse-time-string-chars 2282 25%
- let 2258 25%
- unwind-protect 2170 24%
- progn 2126 23%
- let 176 1%
- cond 160 1%
- string-match 24 0%
setq 16 0%
--8<---------------cut here---------------end--------------->8---
And this one from "emacs -Q":
--8<---------------cut here---------------start------------->8---
- command-execute 2643 90%
- call-interactively 2643 90%
- funcall-interactively 2221 75%
- eval-expression 2013 68%
- eval 2013 68%
- let 2013 68%
- while 2013 68%
- parse-time-string 2002 68%
- let 2002 68%
- parse-time-tokenize 1291 44%
- let 1283 43%
- while 1272 43%
- while 1112 38%
- and 1044 35%
- setq 640 21%
- parse-time-string-chars 608 20%
- let 557 19%
- unwind-protect 461 15%
- progn 401 13%
- let 345 11%
- cond 285 9%
- string-match 56 1%
setq 40 1%
set-match-data 16 0%
- not 288 9%
- setq 268 9%
- parse-time-string-chars 244 8%
- let 208 7%
- unwind-protect 192 6%
- progn 152 5%
- let 120 4%
- cond 112 3%
- string-match 32 1%
setq 32 1%
set-match-data 4 0%
--8<---------------cut here---------------end--------------->8---
It seems to me, that there is a problem with "progn":
Slow emacs:
- progn 4141 46%
- let 436 4%
Fast emacs:
- progn 401 13%
- let 345 11%
What do you think?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 11:09:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> It seems to me, that there is a problem with "progn":
>
> Slow emacs:
> - progn 4141 46%
> - let 436 4%
>
> Fast emacs:
> - progn 401 13%
> - let 345 11%
>
>
> What do you think?
progn is very simple, all its time is spent in evaluating the
arguments. Does profile actually work for primitives?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 11:10:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> It seems to me, that there is a problem with "progn":
What do you get when you remove the ‘save-match-data’ in
‘parse-time-string-chars’?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 11:31:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 21 2016, martin rudalics wrote:
> What do you get when you remove the ‘save-match-data’ in
> ‘parse-time-string-chars’?
Fast emacs:
- parse-time-string-chars 386 19%
- let 342 17%
Slow emacs:
- parse-time-string-chars 4122 20%
- let 404 1%
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 13:42:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Hi,
just a shot in the dark: does (length parse-time-rules) increase when
the thing gets slower?
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 14:03:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 21 2016, Michael Heerdegen wrote:
> just a shot in the dark: does (length parse-time-rules) increase when
> the thing gets slower?
No. In all cases it's 13.
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 14:37:01 GMT)
Full text and
rfc822 format available.
Message #108 received at 18522 <at> debbugs.gnu.org (full text, mbox):
The problem seems to be string-match:
(defun my-parse-time-string-test ()
(let (case-fold-search)
(string-match "x" "x")))
(let ((gc-cons-threshold most-positive-fixnum))
(benchmark-run 1
(dotimes (i 100000) (my-parse-time-string-test))))
Fast emacs: (0.094749241 0 0.0)
Slow emacs: (1.802927531 0 0.0)
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 14:55:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 21 2016, Peter Münster wrote:
> The problem seems to be string-match:
Sorry, I was wrong. The problem seems to be the binding of
case-fold-search:
(defun my-parse-time-string-test ()
(let (case-fold-search)
t))
(let ((gc-cons-threshold most-positive-fixnum))
(benchmark-run 1
(dotimes (i 100000) (my-parse-time-string-test))))
Fast emacs: (0.054105733 0 0.0)
Slow emacs: (1.754813882 0 0.0)
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 16:15:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Sun, 21 Feb 2016 15:54:43 +0100
>
> Sorry, I was wrong. The problem seems to be the binding of
> case-fold-search:
>
> (defun my-parse-time-string-test ()
> (let (case-fold-search)
> t))
>
> (let ((gc-cons-threshold most-positive-fixnum))
> (benchmark-run 1
> (dotimes (i 100000) (my-parse-time-string-test))))
>
> Fast emacs: (0.054105733 0 0.0)
> Slow emacs: (1.754813882 0 0.0)
Does this happen only with this particular symbol, or binding any
symbol slows down?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 18:05:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 21 2016, Eli Zaretskii wrote:
> Does this happen only with this particular symbol, or binding any
> symbol slows down?
It depends on the symbol:
case-fold-search: slow
fill-column: slow
just-a-symbol: fast
custom-file: fast
Can you reproduce it?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 21 Feb 2016 20:46:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Sun, 21 Feb 2016 19:03:49 +0100
>
> On Sun, Feb 21 2016, Eli Zaretskii wrote:
>
> > Does this happen only with this particular symbol, or binding any
> > symbol slows down?
>
> It depends on the symbol:
>
> case-fold-search: slow
> fill-column: slow
> just-a-symbol: fast
> custom-file: fast
>
> Can you reproduce it?
I see a 5-fold slow-down with case-fold-search, not a 30-fold as you
reported.
It sounds like the difference is between buffer-local variables and
global variables. Setting the former will potentially loop over all
the buffers and set the value for every buffer that doesn't have a
local value. See data.c around line 1517. How many buffers do you
have in the "slow" version? I have 230.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 22 Feb 2016 07:38:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 21 2016, Eli Zaretskii wrote:
> How many buffers do you have in the "slow" version? I have 230.
12. (Because regularly I kill unused buffers...)
What happens, if you kill 90% of your buffers?
Does my-parse-time-string-test get faster?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 22 Feb 2016 16:24:01 GMT)
Full text and
rfc822 format available.
Message #126 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Mon, 22 Feb 2016 08:37:29 +0100
>
> On Sun, Feb 21 2016, Eli Zaretskii wrote:
>
> > How many buffers do you have in the "slow" version? I have 230.
>
> 12. (Because regularly I kill unused buffers...)
Curiouser and curiouser...
I just tried this in another, larger session (with more than 500
buffers), and got a 10-fold slowdown there. So this is definitely
correlated to some measure of the session's size, although perhaps
not the number of the buffers. Plus, it sounds like symbols that can
be buffer-local share this problem. Can you try several more
buffer-local and not buffer-local symbols, to see if indeed the
conclusion is valid?
> What happens, if you kill 90% of your buffers?
Sorry, I can't: this is my main session where I do everything. And
chances are killing them won't change the results, judging by your
measurements.
I think the next step is to profile the code below "let". Can you try
using 'perf' for that purpose?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 22 Feb 2016 20:42:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 22 2016, Eli Zaretskii wrote:
> I think the next step is to profile the code below "let". Can you try
> using 'perf' for that purpose?
Slow emacs: almost all time is spent in Fset_default (96%)
Fast emacs:
25.36% emacs emacs [.] eval_sub
10.73% emacs emacs [.] Fset_default
9.63% emacs emacs [.] Flength
6.54% emacs emacs [.] unbind_to
5.44% emacs emacs [.] hash_lookup
4.53% emacs emacs [.] Flet
You can try it too on your running sessions: "perf record -p PID" and
then "perf report". (just use something like "dotimes (i 1000000000)")
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 22 Feb 2016 20:58:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Mon, 22 Feb 2016 21:41:11 +0100
>
> On Mon, Feb 22 2016, Eli Zaretskii wrote:
>
> > I think the next step is to profile the code below "let". Can you try
> > using 'perf' for that purpose?
>
> Slow emacs: almost all time is spent in Fset_default (96%)
>
> Fast emacs:
> 25.36% emacs emacs [.] eval_sub
> 10.73% emacs emacs [.] Fset_default
> 9.63% emacs emacs [.] Flength
> 6.54% emacs emacs [.] unbind_to
> 5.44% emacs emacs [.] hash_lookup
> 4.53% emacs emacs [.] Flet
So now the question becomes: which part of Fset_default? I thought it
was the loop over all the buffers, but your session seems to say it
couldn't be. Then what is it?
> You can try it too on your running sessions: "perf record -p PID" and
> then "perf report". (just use something like "dotimes (i 1000000000)")
Alas, there's no 'perf' on MS-Windows (nor anything like it, AFAIK).
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Tue, 23 Feb 2016 11:20:01 GMT)
Full text and
rfc822 format available.
Message #135 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 22 2016, Eli Zaretskii wrote:
> So now the question becomes: which part of Fset_default? I thought it
> was the loop over all the buffers, but your session seems to say it
> couldn't be.
Why?
This is what I read in buffer.h:
--8<---------------cut here---------------start------------->8---
/* Chain of all buffers, including killed ones. */
extern struct buffer *all_buffers;
/* Used to iterate over the chain above. */
#define FOR_EACH_BUFFER(b) \
for ((b) = all_buffers; (b); (b) = (b)->next)
--8<---------------cut here---------------end--------------->8---
"including killed ones" !
That means, the chain gets bigger and bigger, whenever I read an article
or I reply or I send a new message or whatever.
I've added a small patch to Fset_default:
--8<---------------cut here---------------start------------->8---
struct buffer *b;
int i = 0;
FOR_EACH_BUFFER (b) {
i++;
if (!PER_BUFFER_VALUE_P (b, idx))
set_per_buffer_value (b, offset, value);
}
fprintf(stderr, "length of all_buffers: %d\n", i);
--8<---------------cut here---------------end--------------->8---
Let's see, how the chain grows... (or not)
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Tue, 23 Feb 2016 16:25:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Tue, 23 Feb 2016 12:19:30 +0100
>
> On Mon, Feb 22 2016, Eli Zaretskii wrote:
>
> > So now the question becomes: which part of Fset_default? I thought it
> > was the loop over all the buffers, but your session seems to say it
> > couldn't be.
>
> Why?
Because your session has very few buffers, and yet you see a much more
massive slowdown.
> This is what I read in buffer.h:
>
> --8<---------------cut here---------------start------------->8---
> /* Chain of all buffers, including killed ones. */
>
> extern struct buffer *all_buffers;
>
> /* Used to iterate over the chain above. */
>
> #define FOR_EACH_BUFFER(b) \
> for ((b) = all_buffers; (b); (b) = (b)->next)
> --8<---------------cut here---------------end--------------->8---
>
> "including killed ones" !
You interpret that comment too literally: it means killed buffers that
were not yet GC'ed. You will see in alloc.c that sweep_buffers
removes killed buffers from all_buffers and recycles their memory.
> That means, the chain gets bigger and bigger, whenever I read an article
> or I reply or I send a new message or whatever.
If Emacs did that, it would have been a very serious bug and a huge
memory sink.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Tue, 23 Feb 2016 16:37:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Tue, Feb 23 2016, Eli Zaretskii wrote:
> You interpret that comment too literally: it means killed buffers that
> were not yet GC'ed. You will see in alloc.c that sweep_buffers
> removes killed buffers from all_buffers and recycles their memory.
Ok, thanks for the explanation.
My current emacs session is running now since 5 hours. The length of the
chain is 131. And this is my buffer list:
.%* *Article inbox* 1592 Article
%* *Summary inbox* 85 Summary
% *Group* 41 Group
%* *Completions* 180 Completion List
*scratch* 141 Lisp Interaction
%* *Messages* 446718 Messages
* todo.org 147282 Org ~/todo/todo.org
I guess, that the slow-down is related to the chain-length. What do you think?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Tue, 23 Feb 2016 16:49:01 GMT)
Full text and
rfc822 format available.
Message #144 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> My current emacs session is running now since 5 hours. The length of the
> chain is 131. And this is my buffer list:
>
> .%* *Article inbox* 1592 Article
> %* *Summary inbox* 85 Summary
> % *Group* 41 Group
> %* *Completions* 180 Completion List
> *scratch* 141 Lisp Interaction
> %* *Messages* 446718 Messages
> * todo.org 147282 Org ~/todo/todo.org
Note that buffers starting with a space are hidden from C-x C-b. You
can only see them in (buffer-list), or by completing a space in C-x b.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Tue, 23 Feb 2016 17:48:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Tue, 23 Feb 2016 17:35:50 +0100
>
> My current emacs session is running now since 5 hours. The length of the
> chain is 131. And this is my buffer list:
>
> .%* *Article inbox* 1592 Article
> %* *Summary inbox* 85 Summary
> % *Group* 41 Group
> %* *Completions* 180 Completion List
> *scratch* 141 Lisp Interaction
> %* *Messages* 446718 Messages
> * todo.org 147282 Org ~/todo/todo.org
>
> I guess, that the slow-down is related to the chain-length. What do you think?
We need to time that loop to be sure. Can you do that with 'perf', or
add a call to gettimeofday before and after, and see how much time it
takes as the list of buffers grows?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 10:23:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Tue, Feb 23 2016, Andreas Schwab wrote:
> Note that buffers starting with a space are hidden from C-x C-b. You
> can only see them in (buffer-list), or by completing a space in C-x b.
Ok. There are some hidden buffers (from Gnus).
(length (buffer-list)) -> 27
length of all_buffers -> 162
What do you think about the difference? Bug or not?
Any explanation?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 10:26:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Tue, Feb 23 2016, Eli Zaretskii wrote:
> We need to time that loop to be sure. Can you do that with 'perf',
How please?
> or add a call to gettimeofday before and after, and see how much time
> it takes as the list of buffers grows?
Then, I would need to restart emacs. If it's possible to measure the
time without restarting it, that would be better.
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 10:36:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> You interpret that comment too literally: it means killed buffers that
> were not yet GC'ed. You will see in alloc.c that sweep_buffers
> removes killed buffers from all_buffers and recycles their memory.
Doesn't that remove unmarked buffers only?
>> That means, the chain gets bigger and bigger, whenever I read an article
>> or I reply or I send a new message or whatever.
>
> If Emacs did that, it would have been a very serious bug and a huge
> memory sink.
One potential hole are window configurations. Each window maintains two
lists for navigating the buffers previously shown in that window. For
live windows, these lists are hopefully updated when killing a buffer.
But if you store such a window in a window configuration and forget
about that configuration, the buffers from those lists are not reclaimed
IIUC.
BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 17:40:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Wed, 24 Feb 2016 11:25:10 +0100
>
> On Tue, Feb 23 2016, Eli Zaretskii wrote:
>
> > We need to time that loop to be sure. Can you do that with 'perf',
>
> How please?
"perf annotate", perhaps?
> > or add a call to gettimeofday before and after, and see how much time
> > it takes as the list of buffers grows?
>
> Then, I would need to restart emacs. If it's possible to measure the
> time without restarting it, that would be better.
Yes, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 17:43:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 24 Feb 2016 11:15:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
>
> > You interpret that comment too literally: it means killed buffers that
> > were not yet GC'ed. You will see in alloc.c that sweep_buffers
> > removes killed buffers from all_buffers and recycles their memory.
>
> Doesn't that remove unmarked buffers only?
Of course. But why would killed buffers be marked?
> >> That means, the chain gets bigger and bigger, whenever I read an article
> >> or I reply or I send a new message or whatever.
> >
> > If Emacs did that, it would have been a very serious bug and a huge
> > memory sink.
>
> One potential hole are window configurations. Each window maintains two
> lists for navigating the buffers previously shown in that window. For
> live windows, these lists are hopefully updated when killing a buffer.
> But if you store such a window in a window configuration and forget
> about that configuration, the buffers from those lists are not reclaimed
> IIUC.
What do you mean by "forget"? Forgetting a Lisp object means it is
not referenced by any other object, so it will be GCed, together with
the buffers it references. Right?
> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.
What would you use instead?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 18:01:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 24 2016, Eli Zaretskii wrote:
> "perf annotate", perhaps?
Thanks, what a great tool!
perf report:
33.17% emacs emacs [.] Fset_default
Uptime is only about 1 day now. Length of all_buffers is 207.
perf annotate:
--8<---------------cut here---------------start------------->8---
│ Fset_default():
│ set it in the buffers that don't nominally have a local value. */
│ if (idx > 0)
│ {
│ struct buffer *b;
│ int i = 0;
│ FOR_EACH_BUFFER (b)
15.68 │101: mov 0x2d8(%rcx),%rcx
19.34 │ test %rcx,%rcx
5.39 │ ↑ jne f0
│ {
│ i++;
│ if (!PER_BUFFER_VALUE_P (b, idx))
│ set_per_buffer_value (b, offset, value);
│ }
│ fprintf(stderr, "XXXXX: %d\n", i);
0.07 │10d: mov stderr@@GLIBC_2.2.5,%rdi
2.49 │ mov $0x5e90e5,%esi
│ xor %eax,%eax
--8<---------------cut here---------------end--------------->8---
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 18:17:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> Of course. But why would killed buffers be marked?
Because they are still referenced from somewhere else.
> What do you mean by "forget"? Forgetting a Lisp object means it is
> not referenced by any other object, so it will be GCed, together with
> the buffers it references. Right?
Each window in a window configuration stores all the buffers it has ever
shown. Now window configurations are sometimes stored in registers. I
could imagine users that store a couple of configurations in registers
and "forget" about them in the sense that they do not restore from some
of those stored configurations for quite some time or the rest of the
session.
>> BTW, I have no idea why FOR_EACH_BUFFER should be used outside alloc.c.
>
> What would you use instead?
A macro that excludes killed buffers. What's the purpose of
if (!PER_BUFFER_VALUE_P (b, idx))
set_per_buffer_value (b, offset, value);
in a killed buffer?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 18:24:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Wed, 24 Feb 2016 19:00:07 +0100
>
> perf report:
>
> 33.17% emacs emacs [.] Fset_default
>
> Uptime is only about 1 day now. Length of all_buffers is 207.
>
> perf annotate:
>
> --8<---------------cut here---------------start------------->8---
> │ Fset_default():
> │ set it in the buffers that don't nominally have a local value. */
> │ if (idx > 0)
> │ {
> │ struct buffer *b;
> │ int i = 0;
> │ FOR_EACH_BUFFER (b)
> 15.68 │101: mov 0x2d8(%rcx),%rcx
> 19.34 │ test %rcx,%rcx
> 5.39 │ ↑ jne f0
> │ {
> │ i++;
> │ if (!PER_BUFFER_VALUE_P (b, idx))
> │ set_per_buffer_value (b, offset, value);
> │ }
> │ fprintf(stderr, "XXXXX: %d\n", i);
> 0.07 │10d: mov stderr@@GLIBC_2.2.5,%rdi
> 2.49 │ mov $0x5e90e5,%esi
> │ xor %eax,%eax
> --8<---------------cut here---------------end--------------->8---
What is that "f0" there? Can you annotate it as well? Otherwise,
this makes no sense to me: the part that takes most of the time is 2
simple instructions. Sounds like we are looking at too small portion
of the code, so these are percents of a very small fraction of the
total running time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 18:50:01 GMT)
Full text and
rfc822 format available.
Message #174 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> Each window in a window configuration stores all the buffers it has ever
> shown. Now window configurations are sometimes stored in registers. I
> could imagine users that store a couple of configurations in registers
> and "forget" about them in the sense that they do not restore from some
> of those stored configurations for quite some time or the rest of the
> session.
I just noticed that Stefan fixed that scenario back in 2012. Anyway,
something similar seems to happen on Peter's machine. 162 buffers with
only 27 live ones cannot be explained by large GC intervals.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 20:04:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 24 2016, Eli Zaretskii wrote:
> What is that "f0" there? Can you annotate it as well?
Sorry, I thought, that only the part after "Fset_default():" was
important. Here something more complete:
--8<---------------cut here---------------start------------->8---
│ /* If this variable is not always local in all buffers,
│ set it in the buffers that don't nominally have a local value. */
│ if (idx > 0)
│ ↑ jle 95
│ {
│ struct buffer *b;
│ int i = 0;
│ FOR_EACH_BUFFER (b)
0.08 │ mov all_buffers,%rcx
│ test %rcx,%rcx
│ ↓ je 180
│ {
│ i++;
│ if (!PER_BUFFER_VALUE_P (b, idx))
0.02 │ cmp last_per_buffer_idx,%edx
│ ↓ jge 160
│ {
│ struct buffer *b;
│ int i = 0;
│ FOR_EACH_BUFFER (b)
│ {
│ i++;
│ mov $0x1,%edx
0.02 │ ↓ jmp f3
│ nop
15.24 │ f0: add $0x1,%edx
│ if (!PER_BUFFER_VALUE_P (b, idx))
14.02 │ f3: cmpb $0x0,0x320(%rcx,%rax,1)
10.65 │ ↓ jne 101
│ set_per_buffer_value():
│ }
│
│ INLINE void
│ set_per_buffer_value (struct buffer *b, int offset, Lisp_Object value)
│ {
│ *(Lisp_Object *)(offset + (char *) b) = value;
14.11 │ mov %rbp,(%rcx,%rsi,1)
│ Fset_default():
│ set it in the buffers that don't nominally have a local value. */
│ if (idx > 0)
│ {
│ struct buffer *b;
│ int i = 0;
│ FOR_EACH_BUFFER (b)
14.36 │101: mov 0x2d8(%rcx),%rcx
21.80 │ test %rcx,%rcx
5.16 │ ↑ jne f0
│ {
│ i++;
│ if (!PER_BUFFER_VALUE_P (b, idx))
│ set_per_buffer_value (b, offset, value);
│ }
│ fprintf(stderr, "XXXXX: %d\n", i);
0.00 │10d: mov stderr@@GLIBC_2.2.5,%rdi
2.18 │ mov $0x5e90e5,%esi
│ xor %eax,%eax
│ → callq fprintf <at> plt
│ ↑ jmpq 95
│ nop
--8<---------------cut here---------------end--------------->8---
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 20:27:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: rudalics <at> gmx.at, larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Wed, 24 Feb 2016 21:03:41 +0100
>
> --8<---------------cut here---------------start------------->8---
> │ /* If this variable is not always local in all buffers,
> │ set it in the buffers that don't nominally have a local value. */
> │ if (idx > 0)
> │ ↑ jle 95
> │ {
> │ struct buffer *b;
> │ int i = 0;
> │ FOR_EACH_BUFFER (b)
> 0.08 │ mov all_buffers,%rcx
> │ test %rcx,%rcx
> │ ↓ je 180
> │ {
> │ i++;
> │ if (!PER_BUFFER_VALUE_P (b, idx))
> 0.02 │ cmp last_per_buffer_idx,%edx
> │ ↓ jge 160
> │ {
> │ struct buffer *b;
> │ int i = 0;
> │ FOR_EACH_BUFFER (b)
> │ {
> │ i++;
> │ mov $0x1,%edx
> 0.02 │ ↓ jmp f3
> │ nop
> 15.24 │ f0: add $0x1,%edx
> │ if (!PER_BUFFER_VALUE_P (b, idx))
> 14.02 │ f3: cmpb $0x0,0x320(%rcx,%rax,1)
> 10.65 │ ↓ jne 101
> │ set_per_buffer_value():
> │ }
> │
> │ INLINE void
> │ set_per_buffer_value (struct buffer *b, int offset, Lisp_Object value)
> │ {
> │ *(Lisp_Object *)(offset + (char *) b) = value;
> 14.11 │ mov %rbp,(%rcx,%rsi,1)
> │ Fset_default():
> │ set it in the buffers that don't nominally have a local value. */
> │ if (idx > 0)
> │ {
> │ struct buffer *b;
> │ int i = 0;
> │ FOR_EACH_BUFFER (b)
> 14.36 │101: mov 0x2d8(%rcx),%rcx
> 21.80 │ test %rcx,%rcx
> 5.16 │ ↑ jne f0
> │ {
> │ i++;
> │ if (!PER_BUFFER_VALUE_P (b, idx))
> │ set_per_buffer_value (b, offset, value);
> │ }
> │ fprintf(stderr, "XXXXX: %d\n", i);
> 0.00 │10d: mov stderr@@GLIBC_2.2.5,%rdi
> 2.18 │ mov $0x5e90e5,%esi
> │ xor %eax,%eax
> │ → callq fprintf <at> plt
> │ ↑ jmpq 95
> │ nop
> --8<---------------cut here---------------end--------------->8---
Most of the time is spent in the loop over the buffers.
So I guess avoiding binding case-fold-search in parse-time-string
should make the problem go away?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 20:28:01 GMT)
Full text and
rfc822 format available.
Message #183 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 24 Feb 2016 19:49:37 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: larsi <at> gnus.org, pmlists <at> free.fr, 18522 <at> debbugs.gnu.org
>
> something similar seems to happen on Peter's machine. 162 buffers with
> only 27 live ones cannot be explained by large GC intervals.
Perhaps showing the names of those extra buffers will give a clue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 24 Feb 2016 23:54:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Just on a hunch -- what's the value of your `gnus-buffers' variable?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 08:07:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 24 2016, Eli Zaretskii wrote:
> So I guess avoiding binding case-fold-search in parse-time-string
> should make the problem go away?
Yes, it does.
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 08:08:01 GMT)
Full text and
rfc822 format available.
Message #192 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Wed, Feb 24 2016, Eli Zaretskii wrote:
> Perhaps showing the names of those extra buffers will give a clue.
Could you provide some code please, to show the names?
TIA,
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 08:09:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 25 2016, Lars Ingebrigtsen wrote:
> Just on a hunch -- what's the value of your `gnus-buffers' variable?
(#<buffer *unsent mail*> #<buffer *sent mail to Eli Zaretskii*<2>> #<buffer *sent mail to Eli Zaretskii*> #<buffer *Article nndraft:drafts*> #<buffer *Original Article nndraft:drafts*> #<buffer *Summary nndraft:drafts*> #<killed buffer> #<buffer *nnmail message-id cache*> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<buffer *MML2015 Result*> #<killed buffer> #<buffer *gnus article copy*> #<buffer *Gnus Backlog*> #<buffer *gnus work*> #<buffer *Gnus agent overview*> #<buffer *Group*>)
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 10:08:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 18522 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Could you provide some code please, to show the names?
Try ‘killed-buffer-names’ from the attached patch.
martin
[killed-buffer-names.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 16:00:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 18522 <at> debbugs.gnu.org
> Date: Thu, 25 Feb 2016 09:08:44 +0100
>
> > Just on a hunch -- what's the value of your `gnus-buffers' variable?
>
> (#<buffer *unsent mail*> #<buffer *sent mail to Eli Zaretskii*<2>> #<buffer
> *sent mail to Eli Zaretskii*> #<buffer *Article nndraft:drafts*> #<buffer
> *Original Article nndraft:drafts*> #<buffer *Summary nndraft:drafts*> #<killed
> buffer> #<buffer *nnmail message-id cache*> #<killed buffer> #<killed buffer>
> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed
> buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer>
> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed
> buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer>
> #<killed buffer> #<killed buffer> #<buffer *MML2015 Result*> #<killed buffer>
> #<buffer *gnus article copy*> #<buffer *Gnus Backlog*> #<buffer *gnus work*>
> #<buffer *Gnus agent overview*> #<buffer *Group*>)
OK, so is the following summary of this long discussion accurate?
. Peter noticed that Gnus is very slow entering a group
. Gnus is slow because parse-time-string takes a lot of time
. parse-time-string is slow because it let-binds case-fold-search
. binding case-fold-search is slow because Peter has a lot of
buffers, which set-default loops over to change the value of
case-fold-search in each one of them
. most of the buffers over which set-default loops were actually
killed, but they are still in all_buffers list which set-default
traverses, although they were supposed to be removed by GC
. killed buffers are not removed from all_buffers by GC because
they are referenced by gnus-buffers
. gnus-buffers references killed buffers because Peter kills buffers
behind Gnus back, instead of letting them be killed through
gnus-kill-buffer, which would have removed them from gnus-buffers
If the above is an accurate account of what we've discovered, then we
have several factors here that conspire to make Peter's Gnus slow:
. parse-time-string should try to avoid binding case-fold-search
globally, or at all
. set-default should skip killed buffers
. Peter should stop killing Gnus buffers behind Gnus back
For the first issue, I propose to modify parse-time-string to use
upcase and downcase instead of string-match. E.g., this:
(/= (downcase char) char)
can be used to detect upper-case characters, and similarly with
lower-case.
For the second issue, I propose to modify set-default to use
FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER. Does anyone see a
problem with that?
For the third issue, Peter should make his buffer-killing code look in
gnus-buffers, and kill any buffers referenced by it through
gnus-kill-buffer. If this involves some standard Emacs features (like
'midnight', perhaps), then those features should also be adapted to
gnus-buffers.
Comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 18:12:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 25 2016, Eli Zaretskii wrote:
> . gnus-buffers references killed buffers because Peter kills buffers
> behind Gnus back, instead of letting them be killed through
> gnus-kill-buffer, which would have removed them from gnus-buffers
This point is perhaps not 100% accurate. After 6h running, here some
more details about the situation:
- length of all_buffers: 74
- length of buffer-list: 45
- length of killed-buffer-names: 28
- length of gnus-buffers: 17
Content of killed-buffer-names:
Name Details
-----------------------------------------------------------------------------
" *mm*" ???
" *mm*-292588" ???
" *mm*-331546" ???
" *mm*-391449" ???
" *mm*-531130" ???
" *mm*-59524" ???
" *mm*-705438" ???
" *mm*-971636" ???
" *nnmail message-id cache*" ???
" *nnml overview inbox*" ???
" *server news.gmane.org nntp *nntpd**" ???
" *server news.gmane.org nntp *nntpd**" ???
" *server news.povray.org nntp *nntpd**" ???
" *server news.povray.org nntp *nntpd**" ???
"*Backtrace*" killed by me with kill-buffer
"*Completions*" killed by me with kill-buffer
"*Completions*" killed by me with kill-buffer
"*Help*" killed by me with kill-buffer
"*Summary nndraft:drafts*" killed by gnus-summary-exit
"*Summary nntp+news.gmane.org:gmane.comp.
embedded.openwrt.user*" killed by gnus-summary-exit
"*sent mail to SAV*" killed by me with kill-buffer
"*sent mail to XXX*" killed by me with kill-buffer
"*sent mail to YYY*" killed by me with kill-buffer
"*unsent wide reply to Eli Zaretskii*" killed by me with kill-buffer
"*unsent wide reply to SAV*" killed by me with kill-buffer
"*unsent wide reply to ZZZ*" killed by me with kill-buffer
"gnus-util.el" killed by me with kill-buffer
"jl-encrypt.el" killed by me with kill-buffer
There are 6 "#<killed buffer>" in gnus-buffers. That means, that I
should have killed the 6 buffers "*sent ..." and "*unsent ..." with
gnus-kill-buffer. I'll do that in the future. But what about the other buffers?
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Thu, 25 Feb 2016 18:26:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Thu, 25 Feb 2016 19:10:58 +0100
>
> On Thu, Feb 25 2016, Eli Zaretskii wrote:
>
> > . gnus-buffers references killed buffers because Peter kills buffers
> > behind Gnus back, instead of letting them be killed through
> > gnus-kill-buffer, which would have removed them from gnus-buffers
>
> This point is perhaps not 100% accurate. After 6h running, here some
> more details about the situation:
>
> - length of all_buffers: 74
> - length of buffer-list: 45
> - length of killed-buffer-names: 28
> - length of gnus-buffers: 17
>
> Content of killed-buffer-names:
>
> Name Details
> -----------------------------------------------------------------------------
> " *mm*" ???
> " *mm*-292588" ???
> " *mm*-331546" ???
> " *mm*-391449" ???
> " *mm*-531130" ???
> " *mm*-59524" ???
> " *mm*-705438" ???
> " *mm*-971636" ???
> " *nnmail message-id cache*" ???
> " *nnml overview inbox*" ???
> " *server news.gmane.org nntp *nntpd**" ???
> " *server news.gmane.org nntp *nntpd**" ???
> " *server news.povray.org nntp *nntpd**" ???
> " *server news.povray.org nntp *nntpd**" ???
> "*Backtrace*" killed by me with kill-buffer
> "*Completions*" killed by me with kill-buffer
> "*Completions*" killed by me with kill-buffer
> "*Help*" killed by me with kill-buffer
> "*Summary nndraft:drafts*" killed by gnus-summary-exit
> "*Summary nntp+news.gmane.org:gmane.comp.
> embedded.openwrt.user*" killed by gnus-summary-exit
> "*sent mail to SAV*" killed by me with kill-buffer
> "*sent mail to XXX*" killed by me with kill-buffer
> "*sent mail to YYY*" killed by me with kill-buffer
> "*unsent wide reply to Eli Zaretskii*" killed by me with kill-buffer
> "*unsent wide reply to SAV*" killed by me with kill-buffer
> "*unsent wide reply to ZZZ*" killed by me with kill-buffer
> "gnus-util.el" killed by me with kill-buffer
> "jl-encrypt.el" killed by me with kill-buffer
>
> There are 6 "#<killed buffer>" in gnus-buffers. That means, that I
> should have killed the 6 buffers "*sent ..." and "*unsent ..." with
> gnus-kill-buffer. I'll do that in the future. But what about the other buffers?
The *mm*-NNN buffers sound like something related to Gnus mail, so I
defer to you and Lars for describing their life cycle.
Likewise with *nnmail...*" and *server news....* buffers.
(It's quite possible that these were also killed by you at some
inopportune moment, btw, and that's why they are still around. Can
you describe in more detail how you kill buffers? Or maybe try
running for a few days without killing buffers, except manually when
you are done with visiting some file, and see what winds up in the
list of killed buffers?)
*Completions*, *Help*, and *Backtrace* -- simply don't kill them, it's
useless. They will pop up again soon enough.
In any case, the other 2 measures should fix the original problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 03:15:01 GMT)
Full text and
rfc822 format available.
Message #210 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> . most of the buffers over which set-default loops were actually
> killed, but they are still in all_buffers list which set-default
> traverses, although they were supposed to be removed by GC
> . killed buffers are not removed from all_buffers by GC because
> they are referenced by gnus-buffers
> . gnus-buffers references killed buffers because Peter kills buffers
> behind Gnus back, instead of letting them be killed through
> gnus-kill-buffer, which would have removed them from gnus-buffers
It's probably not just Peter, but... code somewhere. My gnus-buffers
is currently:
(#<buffer *unsent wide reply to Eli Zaretskii*> #<buffer *Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *Original Article nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *Summary nnimap+hermes.netfonds.no:emacs-devel*> #<buffer *sent wide reply to Eli Zaretskii*> #<buffer *sent wide reply to Richard Stallman*> #<killed buffer> #<buffer *sent wide reply to Thierry Volpiatto*> #<buffer *sent wide reply to Lars Magne Ingebrigtsen*> #<buffer *sent wide reply to Matthew Styskal*> #<buffer *sent wide reply to Paul Eggert*<3>> #<buffer *sent wide reply to Zachary Kanfer*> #<buffer *sent wide reply to David Engster*> #<buffer *sent wide reply to Paul Eggert*<2>> #<buffer *sent wide reply to Paul Eggert*> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<killed buffer> #<buffer *gnus article copy*> #<killed buffer> #<buffer *nnmail message-id cache*> #<buffer *nnimap hermes.netfonds.no nil *nntpd**> #<buffer *gnus work*> #<buffer .newsrc-dribble> #<buffer *Gnus agent overview*> #<buffer *Group*>)
I'll fix the gnus-{add,kill}-buffer functions so that they remove all
the killed buffers. That should help keep that list down to a
reasonable length, and let all the killed buffers be GC'd.
> If the above is an accurate account of what we've discovered, then we
> have several factors here that conspire to make Peter's Gnus slow:
>
> . parse-time-string should try to avoid binding case-fold-search
> globally, or at all
It's kinda weird. This starts with:
(defun parse-time-string (string)
[...]
(temp (parse-time-tokenize (downcase string))))
which calls
(defsubst parse-time-string-chars (char)
(save-match-data
(let (case-fold-search str)
(cond ((eq char ?+) 1)
((eq char ?-) -1)
((eq char ?:) ?d)
((string-match "[[:upper:]]" (setq str (string char))) ?A)
((string-match "[[:lower:]]" str) ?a)
((string-match "[[:digit:]]" str) ?0)))))
!?
Since we've already downcased the entire string, both the
`case-fold-search' and the match to [[:upper:]] seem rather
nonsensical? So that should be fixed, but:
> . set-default should skip killed buffers
Yes. I think that would be a win in general.
> For the second issue, I propose to modify set-default to use
> FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER. Does anyone see a
> problem with that?
Hm... If a buffer is killed, do the local variables still have an
effect? I'm thinking of code like:
(with-temp-buffer
(setq-local foo 'bar)
(kill-buffer (current-buffer))
(let ((buf (current-buffer)))
(with-temp-buffer
(let ((foo 'zot))
(set-buffer buf)
foo))))
Well, that answered itself. :-) It returns zot. (If we don't kill it
returns bar.) So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 03:20:02 GMT)
Full text and
rfc822 format available.
Message #213 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> Name Details
> -----------------------------------------------------------------------------
> " *mm*" ???
> " *mm*-292588" ???
> " *mm*-331546" ???
> " *mm*-391449" ???
> " *mm*-531130" ???
> " *mm*-59524" ???
> " *mm*-705438" ???
> " *mm*-971636" ???
Hm... could these be from `mml-buffer-list'? Which is a list I've
just discovered. No, that's something else... I wonder where these are
coming from. That is, Gnus creates " *mm*" buffers a lot, but I can't
see where Gnus is keeping them in a list...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 08:49:01 GMT)
Full text and
rfc822 format available.
Message #216 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Peter Münster <pmlists <at> free.fr>,
> 18522 <at> debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
>
> > . parse-time-string should try to avoid binding case-fold-search
> > globally, or at all
>
> It's kinda weird. This starts with:
>
> (defun parse-time-string (string)
>
> [...]
>
> (temp (parse-time-tokenize (downcase string))))
>
> which calls
>
> (defsubst parse-time-string-chars (char)
> (save-match-data
> (let (case-fold-search str)
> (cond ((eq char ?+) 1)
> ((eq char ?-) -1)
> ((eq char ?:) ?d)
> ((string-match "[[:upper:]]" (setq str (string char))) ?A)
> ((string-match "[[:lower:]]" str) ?a)
> ((string-match "[[:digit:]]" str) ?0)))))
>
> !?
>
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical?
Yes, weird. And even if someone thought of using
parse-time-string-chars in other places that don't necessarily
downcase the string, I don't understand why we should test a character
by making it a string, then matching against [:upper:]. Maybe I'm
missing something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 09:29:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Peter Münster <pmlists <at> free.fr>,
> 18522 <at> debbugs.gnu.org
> Date: Fri, 26 Feb 2016 13:43:44 +1030
>
> Since we've already downcased the entire string, both the
> `case-fold-search' and the match to [[:upper:]] seem rather
> nonsensical? So that should be fixed, but:
>
> > . set-default should skip killed buffers
>
> Yes. I think that would be a win in general.
>
> > For the second issue, I propose to modify set-default to use
> > FOR_EACH_LIVE_BUFFER instead of FOR_EACH_BUFFER. Does anyone see a
> > problem with that?
>
> Hm... If a buffer is killed, do the local variables still have an
> effect? I'm thinking of code like:
>
> (with-temp-buffer
> (setq-local foo 'bar)
> (kill-buffer (current-buffer))
> (let ((buf (current-buffer)))
> (with-temp-buffer
> (let ((foo 'zot))
> (set-buffer buf)
> foo))))
>
> Well, that answered itself. :-) It returns zot. (If we don't kill it
> returns bar.) So I don't see any reason not to use FOR_EACH_LIVE_BUFFER
> here.
Btw, why did you fix all those on master? I think this should be
fixed on emacs-25 instead.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 11:06:02 GMT)
Full text and
rfc822 format available.
Message #222 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Thu, Feb 25 2016, Eli Zaretskii wrote:
> Can you describe in more detail how you kill buffers?
In summary buffers, I press "q" (gnus-summary-exit).
In other buffers, I press M-k (bound to kill-this-buffer).
> Or maybe try running for a few days without killing buffers, except
> manually when you are done with visiting some file, and see what winds
> up in the list of killed buffers?)
Ok.
> *Completions*, *Help*, and *Backtrace* -- simply don't kill them, it's
> useless. They will pop up again soon enough.
I know, but the habit to kill useless buffers is in my fingers already
for a long time...
> In any case, the other 2 measures should fix the original problem.
If the case really doesn't matter in a time-string, then of course just
down-case the string and then parse it.
But I think, that we have found another issue (just a very tiny one):
the number of killed buffers, that are not GCed, keeps growing.
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 11:15:02 GMT)
Full text and
rfc822 format available.
Message #225 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: larsi <at> gnus.org, 18522 <at> debbugs.gnu.org
> Date: Fri, 26 Feb 2016 12:05:12 +0100
>
> If the case really doesn't matter in a time-string, then of course just
> down-case the string and then parse it.
I proposed a change there that will support mixed case, but won't need
to bind case-fold-search. We could use that instead.
> But I think, that we have found another issue (just a very tiny one):
> the number of killed buffers, that are not GCed, keeps growing.
Indeed. I believe Lars is working on this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Fri, 26 Feb 2016 11:36:02 GMT)
Full text and
rfc822 format available.
Message #228 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Fri, Feb 26 2016, Eli Zaretskii wrote:
>> But I think, that we have found another issue (just a very tiny one):
>> the number of killed buffers, that are not GCed, keeps growing.
>
> Indeed. I believe Lars is working on this.
It's not only about Gnus buffers. Here some buffer names from my current
killed-buffer-names list:
"*Completions*" "*Backtrace*" "gnus-util.el" "jl-encrypt.el"
"*Completions*" "*Help*" "*Choices*" "misc" "quittance-greenever.tex"
"*~/ctx/misc/quittance-greenever output*" "*Choices*" "custom.el"
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 04:04:02 GMT)
Full text and
rfc822 format available.
Message #231 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> (defsubst parse-time-string-chars (char)
>> (save-match-data
>> (let (case-fold-search str)
>> (cond ((eq char ?+) 1)
>> ((eq char ?-) -1)
>> ((eq char ?:) ?d)
>> ((string-match "[[:upper:]]" (setq str (string char))) ?A)
>> ((string-match "[[:lower:]]" str) ?a)
>> ((string-match "[[:digit:]]" str) ?0)))))
[...]
> Yes, weird. And even if someone thought of using
> parse-time-string-chars in other places that don't necessarily
> downcase the string, I don't understand why we should test a character
> by making it a string, then matching against [:upper:]. Maybe I'm
> missing something.
No, that's also rather puzzling. Looking at the rest of the code, we
don't really handle anything other than [a-z] and [0-9] here, so using a
regexp instead of a (<= ?0 char ?9) (etc.) also seems odd. And losing
those `string-match' calls would also mean we could get rid of the
`save-match-data' call.
I think I'll put together a test harness for `parse-time' and then clean
up this function further.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 04:05:01 GMT)
Full text and
rfc822 format available.
Message #234 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Btw, why did you fix all those on master? I think this should be
> fixed on emacs-25 instead.
I didn't consider this a bug, really, but an optimisation. Besides, no
test harness.
But after more testing, I think we could backport the resulting version
of parse-time.el.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 04:11:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> On Fri, Feb 26 2016, Eli Zaretskii wrote:
>
>>> But I think, that we have found another issue (just a very tiny one):
>>> the number of killed buffers, that are not GCed, keeps growing.
>>
>> Indeed. I believe Lars is working on this.
>
> It's not only about Gnus buffers. Here some buffer names from my current
> killed-buffer-names list:
> "*Completions*" "*Backtrace*" "gnus-util.el" "jl-encrypt.el"
> "*Completions*" "*Help*" "*Choices*" "misc" "quittance-greenever.tex"
> "*~/ctx/misc/quittance-greenever output*" "*Choices*" "custom.el"
There may be other lists that keep track of those buffers...
Try evaling the following and post the list appearing in *Messages*:
(mapatoms
(lambda (symbol)
(when (boundp symbol)
(let ((value (symbol-value symbol)))
(while (consp value)
(let ((elem (car value)))
(when (bufferp elem)
(message "%s has a buffer %s"
symbol (buffer-name elem))))
(setq value (cdr value))))))
obarray)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 05:13:01 GMT)
Full text and
rfc822 format available.
Message #240 received at 18522 <at> debbugs.gnu.org (full text, mbox):
I've now rewritten that function to not use all those regexp and stuff,
and I'm pleased to say that
(benchmark-run 1
(dotimes (i 100000)
(parse-time-string "Fri, 13 Feb 2015 14:40:02 +0000")))
went from approx 9 seconds on my computer to 3.5 seconds (in fresh -Q
Emacsen). :-) (I haven't measured whether that's because it's creating
less garbage or just because it's ... faster.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 08:08:01 GMT)
Full text and
rfc822 format available.
Message #243 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 28 2016, Lars Ingebrigtsen wrote:
> Try evaling the following and post the list appearing in *Messages*:
>
> (mapatoms
> (lambda (symbol)
> (when (boundp symbol)
> (let ((value (symbol-value symbol)))
> (while (consp value)
> (let ((elem (car value)))
> (when (bufferp elem)
> (message "%s has a buffer %s"
> symbol (buffer-name elem))))
> (setq value (cdr value))))))
> obarray)
multi-web-global-mode-buffers has a buffer *Minibuf-1*
rfn-eshadow-frobbed-minibufs has a buffer *Minibuf-1*
gnus-buffers has a buffer *Article nndraft:drafts*
gnus-buffers has a buffer *Original Article nndraft:drafts*
gnus-buffers has a buffer *Summary nndraft:drafts*
gnus-buffers has a buffer nil
gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
gnus-buffers has a buffer *gnus article copy*
gnus-buffers has a buffer *nnmail message-id cache*
gnus-buffers has a buffer *Gnus Backlog*
gnus-buffers has a buffer *gnus work*
gnus-buffers has a buffer *Gnus agent overview*
gnus-buffers has a buffer *Group*
And then I have to stop it with C-g because it hangs...
I had to restart emacs this morning, there are no more *Help* and
*Completions* buffers in the killed list. But there is "gnus-util.el".
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Sun, 28 Feb 2016 15:49:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 18522 <at> debbugs.gnu.org (full text, mbox):
> From: Peter Münster <pmlists <at> free.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 18522 <at> debbugs.gnu.org
> Date: Sun, 28 Feb 2016 09:07:08 +0100
>
> On Sun, Feb 28 2016, Lars Ingebrigtsen wrote:
>
> > Try evaling the following and post the list appearing in *Messages*:
> >
> > (mapatoms
> > (lambda (symbol)
> > (when (boundp symbol)
> > (let ((value (symbol-value symbol)))
> > (while (consp value)
> > (let ((elem (car value)))
> > (when (bufferp elem)
> > (message "%s has a buffer %s"
> > symbol (buffer-name elem))))
> > (setq value (cdr value))))))
> > obarray)
>
> multi-web-global-mode-buffers has a buffer *Minibuf-1*
> rfn-eshadow-frobbed-minibufs has a buffer *Minibuf-1*
> gnus-buffers has a buffer *Article nndraft:drafts*
> gnus-buffers has a buffer *Original Article nndraft:drafts*
> gnus-buffers has a buffer *Summary nndraft:drafts*
> gnus-buffers has a buffer nil
> gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
> gnus-buffers has a buffer *gnus article copy*
> gnus-buffers has a buffer *nnmail message-id cache*
> gnus-buffers has a buffer *Gnus Backlog*
> gnus-buffers has a buffer *gnus work*
> gnus-buffers has a buffer *Gnus agent overview*
> gnus-buffers has a buffer *Group*
>
> And then I have to stop it with C-g because it hangs...
So there's a symbol-value there whose cdr equal's itself? That should
be easy to protect against, no?
Also, I'd suggest disabling GCC during the time this runs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 29 Feb 2016 02:23:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 18522 <at> debbugs.gnu.org (full text, mbox):
Peter Münster <pmlists <at> free.fr> writes:
> And then I have to stop it with C-g because it hangs...
Probably a circular list somewhere. Try the following:
(let ((table (make-hash-table :test 'eq)))
(mapatoms
(lambda (symbol)
(when (boundp symbol)
(let ((value (symbol-value symbol)))
(while (and (consp value)
(not (gethash value table)))
(let ((elem (car value)))
(when (bufferp elem)
(message "%s has a buffer %s"
symbol (buffer-name elem))))
(setf (gethash value table) t)
(setq value (cdr value))))))
obarray))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Mon, 29 Feb 2016 10:34:02 GMT)
Full text and
rfc822 format available.
Message #252 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 29 2016, Lars Ingebrigtsen wrote:
> Probably a circular list somewhere. Try the following:
Output:
multi-web-global-mode-buffers has a buffer *Minibuf-1*
message-buffer-list has a buffer *sent mail to XXX*
rfn-eshadow-frobbed-minibufs has a buffer *Minibuf-1*
gnus-buffers has a buffer *Article nndraft:drafts*
gnus-buffers has a buffer *Original Article nndraft:drafts*
gnus-buffers has a buffer *Summary nndraft:drafts*
gnus-buffers has a buffer *unsent mail*
gnus-buffers has a buffer *nnmail message-id cache*
gnus-buffers has a buffer *sent mail to XXX*
gnus-buffers has a buffer *MML2015 Result*
gnus-buffers has a buffer nil
gnus-buffers has a buffer *unsent wide reply to Lars Ingebrigtsen*
gnus-buffers has a buffer *gnus article copy*
gnus-buffers has a buffer *Gnus Backlog*
gnus-buffers has a buffer *gnus work*
gnus-buffers has a buffer *Gnus agent overview*
gnus-buffers has a buffer *Group*
undo-auto--undoably-changed-buffers has a buffer *Minibuf-1*
global-font-lock-mode-buffers has a buffer *Minibuf-1*
eval-buffer-list has a buffer hugo.el
And here the names of killed buffers:
"*Messages*"
"*GNU Emacs*"
"*Article inbox*"
"*unsent mail*"
"*Summary nndraft:drafts*"
"*Summary nndraft:drafts*"
"*Article nndraft:drafts*"
"gnus-util.el"
"quittance-samson.tex"
--
Peter
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:10:02 GMT)
Full text and
rfc822 format available.
Message #255 received at 18522 <at> debbugs.gnu.org (full text, mbox):
I think the conclusion from this mega-thread was that this was fixed.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 25 Jan 2017 20:10:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
18522 <at> debbugs.gnu.org and Peter Münster <pmlists <at> free.fr>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 25 Jan 2017 20:10:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org, bugs <at> gnus.org:
bug#18522; Package
emacs,gnus.
(Wed, 25 Jan 2017 20:40:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 18522 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jan 25 2017, Lars Ingebrigtsen wrote:
> I think the conclusion from this mega-thread was that this was fixed.
Yes, thanks.
--
Peter
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 23 Feb 2017 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 169 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.