emacs-devel
[Top][All Lists]
Advanced

[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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]