[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 3/3] Start opportunistic GC timer at startup
From: |
Eli Zaretskii |
Subject: |
Re: [PATCH v2 3/3] Start opportunistic GC timer at startup |
Date: |
Sat, 05 Dec 2020 09:52:37 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 04 Dec 2020 18:19:27 -0500
>
> Maybe what I want to compare it against is the number of commands
> during which the GC is run exactly once? The idea is to filter out
> those commands which are compute-intensive and hence run the GC
> internally (for which an opportunistic GC is of no use anyway).
What do you mean by "during which"? Is the time used by redisplay
after a command included or isn't it?
My point is that commands are separate from redisplay in Emacs, and
there's a lot of GC that's unfortunately goes on as part of, or
immediately after, a redisplay cycle in latest versions of Emacs.
> So I added:
>
> (defvar gc--opportunistic-single-gc-cmds 0)
> (let ((last-gcs nil))
> (add-hook 'pre-command-hook (lambda () (setq last-gcs gcs-done)))
> (add-hook 'post-command-hook
> (lambda ()
> (if (eq (1- gcs-done) last-gcs)
> (setq gc--opportunistic-single-gc-cmds
> (1+ gc--opportunistic-single-gc-cmds))))))
>
> So far, this seems to indicate that it's working:
> OT1H `gc--opportunistic-single-gc-cmds` stays much lower than
> `gc--opportunistic-counter`, indicating that we seem to be able to avoid
> GC in many cases, and OTOH `gc--opportunistic-counter` is much lower
> than `gcs-done` indicating that we're not excessively increasing the
> number of GCS.
What is the effect on the memory footprint?