Re: Clarification about auto-revert-mode and inotify

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Tue, 21 Oct 2014 23:20:59 -0400
> 
> > Anyway, if 0.01 s is too expensive, you can always make it 0.2 s,
> > which is also "instantaneous" in human reaction time terms, but is 20
> > times less expensive CPU-wise.
> 
> 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).

> >> I think that with inotify support, we should be able to handle
> >> efficiently (i.e. with prompt refresh and with almost no CPU use when no
> >> files are modified) a situation where the user enabled
> >> global-auto-revert-mode with a 100 file buffers.
> > You do remember that we actually watch the directory of the file, not
> > the file itself, right?  And you do know how the inotify events are
> > processed by Emacs, right?
> 
> I have no idea why that would matter.

You are worried about scalability, and present requirements for it.
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.  (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.)  So processing
notifications on a busy system might itself present scalability
problems and uses up a significant amount of CPU cycles, and I'm not
at all sure the goal of "prompt refresh and almost no CPU use" is
reachable in a way that is scalable to busy directories.

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?

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?

In addition, the proposed way of throttling down the revert rate only
makes sense to me for files that change infrequently, because
frequently modified files will have all but the first modification
delayed.  That doesn't fit the "tail -f" use case, for example.
Sounds like the proposed change is targeting a very narrow niche of
use cases.

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.