From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: lists@dima.secretsauce.net, emacs-devel@gnu.org
Subject: Re: Clarification about auto-revert-mode and inotify
Date: Wed, 22 Oct 2014 13:09:30 -0400 [thread overview]
Message-ID: <jwvr3y0xh9q.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <834muw9n5j.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Oct 2014 17:47:36 +0300")
>> That's better, indeed. The other problem I see with just increasing the
>> timer frequency is the effect it has on those files not covered by
>> inotify (e.g. remote files).
> Maybe we should have 2 separate options, then (if we are going to
> reduce the default time interval).
Maybe we should yes.
> My point is that scalability is not affected only by the number of
> buffers that have auto-revert turned on. In a busy directory, we will
> have to process many notifications that eventually turn out to be for
> files we don't care about. Processing each notification requires
> looping through all the buffers, to find those which have auto-revert
> turned on.
No, we use a hash table to associate buffers to particular
notify-descriptors so we only go through the buffers that do have
auto-revert enabled and that can be affected by changes in this
directory. That can still be a lot of buffers, but is still much better
and that loop can be improved (e.g. hoisting the file-name-nondirectory
out of the loop).
> (We do cut short the search when we find the first client
> buffer for a particular notification, but that doesn't help with
> notifications for which there is no client buffer.)
Yes, I don't think this short cut makes any difference.
> And what about the scalability of the change proposed by Dima? It
> causes each auto-reverted buffer to have its own timer, which would
> mean dozens of timers running to support 100 buffers. Wouldn't that
> slow down Emacs's input loop?
Oh, yes, a timer per buffer would be a bad idea.
> And, of course, the revert operation itself also uses up CPU. The
> relatively long interval we use now in effect collapses all the
> modifications to a file during the last 5 sec into a single revert.
> Reverting "immediately" will revert on each notification, which could
> be quite a lot. How will that affect scalability?
That is indeed a good reason to throttle updates.
> Bottom line, if scalability is a requirement, we need to have a
> broader picture, and then consider the possible solutions based on
> notifications in light of that.
To me the main goals should be:
- *very* low resource use when the system is idle.
- prompt updates after a "one time" change.
- keep Emacs responsive even in case of constant updates.
Stefan
next prev parent reply other threads:[~2014-10-22 17:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 7:00 Clarification about auto-revert-mode and inotify Dima Kogan
2014-10-21 13:43 ` Stefan Monnier
2014-10-21 15:08 ` Eli Zaretskii
2014-10-21 16:28 ` Stefan Monnier
2014-10-21 17:47 ` Eli Zaretskii
2014-10-21 20:23 ` Stefan Monnier
2014-10-21 20:32 ` Eli Zaretskii
2014-10-21 21:32 ` Stefan Monnier
2014-10-22 2:47 ` Eli Zaretskii
2014-10-22 3:20 ` Stefan Monnier
2014-10-22 14:47 ` Eli Zaretskii
2014-10-22 17:09 ` Stefan Monnier [this message]
2014-10-24 7:02 ` Dima Kogan
2014-10-21 17:59 ` Dima Kogan
2014-10-21 18:34 ` Eli Zaretskii
2014-10-21 18:59 ` Dima Kogan
2014-10-21 19:36 ` Eli Zaretskii
2014-10-21 19:39 ` Dima Kogan
2014-10-21 20:09 ` Eli Zaretskii
2014-10-21 20:29 ` Dima Kogan
2014-10-22 2:42 ` Eli Zaretskii
2014-10-22 5:36 ` Per Starbäck
2014-10-22 14:51 ` Eli Zaretskii
2014-10-22 19:08 ` Per Starbäck
2014-10-22 19:35 ` Eli Zaretskii
2014-10-22 10:13 ` Florian Weimer
-- strict thread matches above, loose matches on Subject: below --
2014-10-21 6:01 Dima Kogan
2014-10-21 5:03 Dima Kogan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvr3y0xh9q.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lists@dima.secretsauce.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.