From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Peter Ludemann Newsgroups: gmane.emacs.bugs Subject: bug#38644: 26.3; emacs uses 100% CPU with auto-revert-mode Date: Mon, 6 Jan 2020 16:34:19 -0800 Message-ID: References: <7C3E0AFE-BCA6-4FAF-9EA0-FB0E79BAD443@acm.org> <0723EC9F-3A54-4E84-8D96-EA8D17985A62@acm.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f1a5fd059b81f134" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="138976"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38644@debbugs.gnu.org, Michael Albinus To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 07 01:36:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iocqz-000a2C-Ki for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2020 01:36:13 +0100 Original-Received: from localhost ([::1]:58782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iocqy-0006YZ-1x for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2020 19:36:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57543) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iocqq-0006Vn-33 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 19:36:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iocqo-0001HE-Oi for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 19:36:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41095) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iocqo-0001Gg-It for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 19:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iocqo-0007QL-Dn for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2020 19:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Peter Ludemann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jan 2020 00:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38644 X-GNU-PR-Package: emacs Original-Received: via spool by 38644-submit@debbugs.gnu.org id=B38644.157835730428456 (code B ref 38644); Tue, 07 Jan 2020 00:36:02 +0000 Original-Received: (at 38644) by debbugs.gnu.org; 7 Jan 2020 00:35:04 +0000 Original-Received: from localhost ([127.0.0.1]:47067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iocpr-0007Ou-OQ for submit@debbugs.gnu.org; Mon, 06 Jan 2020 19:35:04 -0500 Original-Received: from mail-lf1-f48.google.com ([209.85.167.48]:33275) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iocpp-0007OJ-V5 for 38644@debbugs.gnu.org; Mon, 06 Jan 2020 19:35:02 -0500 Original-Received: by mail-lf1-f48.google.com with SMTP id n25so37633469lfl.0 for <38644@debbugs.gnu.org>; Mon, 06 Jan 2020 16:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNE0psCYfq1fDs1tPE9JOq0O0ooNIY7MonlAQsvydfQ=; b=VFgI9oC1VxjsVZyxz9RDlnxF0rAmFGMHAcyCbHHoXMaZ1RqTDlnieB9Q/uyvkMv7My KfnRbsILHmsvECD2H0w1Pob/R4VFMtp/iSrTsh9gCpIvIbsmPaTjgUhNhC7kB/vRQq5T JQLRpHEAAaEWTr1HNU41Ei5ssGiGZVo6nFcUZ/xCgr7QvGPJqhK+/DG3ou9Zm6oiR9fT ryuQ4Dp3fl7rINX2eC9PkhE39go01he7IHnybo2NMHXHGOQpxE1IqpugCLuDAL70iXOH 2Abl1QvnApAzBftj2BHctsrTtSxwFE96RRuZWpB5dFPBAOZ3C1+MUllAouJqT5QseEBG ziKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNE0psCYfq1fDs1tPE9JOq0O0ooNIY7MonlAQsvydfQ=; b=Gx7WC33uhqHOnw/Rhug/us3O1BqmPvOqz7C/4PACRP3kg8ARdcrLA7fwJIFCWCyHIt kF2LZ0nl7O2Lnboaqu2lztHqjo97Y+VignFQCjSxHQIsoMg1cYkzemza+Uqx81GK1bjC J/ok1RB9WB5//TNLRVengRt14zoWMUeAPemZr2+jQxXFOEWQkGMR7yYmvfqIUMqkvnpQ Vf7LtJGATzFJHeuD9L/XhMUbfNc0Y0Rnmu+4ZPICTO/k1KSp5g48AsnWMf7bnJJ7AGu+ 8HHFxDlvAm3wNDKbqEcbBiTKEiE578Suc51VudGdMsktTIGnruobvWOAL3WGmT8AzAFu 9J5A== X-Gm-Message-State: APjAAAW802nMFZxF5DxwD+O5PL/OkN9n5XOOzdWlosA28zjagpns7r02 qfTk0P29m6ZDbYsTuGHM3FUwLAbofWEJcenLwqw= X-Google-Smtp-Source: APXvYqy6SuGqQomYgINho9HoEbWILRFJepZhMM9rtN5gIzdlBmACtU+BQGzWGP9i6kFUU82nYz8KmsoX+ZTJVmkt6Lc= X-Received: by 2002:a19:cb54:: with SMTP id b81mr57292582lfg.188.1578357295783; Mon, 06 Jan 2020 16:34:55 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:174279 Archived-At: --000000000000f1a5fd059b81f134 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correction -- the "lock-up" I observed might have been due to paging (possibly related to emacs - I'll have to investigate later). Toggling auto-revert-avoid-polling appeared to reduc emacs CPU usage, according to top(1) - it's a bit difficult to tell because there seems to be some lag in when the command takes effect and my compilation process switches a certain amount between CPU-intensive and IO-intensive. Anyway, CPU seemed to drop from ~60% to ~30% (please take this observation with a large grain of salt). I'll try more things in the future and report if anything interesting shows up. - peter On Mon, 6 Jan 2020 at 16:01, Peter Ludemann wrote: > If anything, auto-revert-avoid-polling makes responsiveness worse -- the > window locked up a few times on me while doing ctrl-N while running a > CPU-intensive (and possibly IO-intensive) compilation. > Although I might not have set the value correctly ... I did M-x > customise-variable RET auto-revert-avoid-polling RET then "toggle" then > "apply". > . > > On Sun, 5 Jan 2020 at 11:57, Mattias Engdeg=C3=A5rd wr= ote: > >> 5 jan. 2020 kl. 20.31 skrev Peter Ludemann : >> >> > Which version of Emacs would you like me to try this with? And what >> result are you expecting/hoping to see? (e.g., might it reduce the curre= nt >> 30-80% CPU load for polling with emacs 28.0.50?) There are only a few op= en >> files directly under /tmp, so would this have any effect or does it >> propagate down to subdirectories? >> > >> > [Also, I'd need a few more details (not being an emacs-internals >> person) ... should I add this to my .emacs and restart, or execute in a >> scratch buffer, or ...?] >> >> 'auto-revert-avoid-polling' is a single global customisable variable, so >> you would set it using >> >> M-x customise-variable RET auto-revert-avoid-polling RET >> >> , then turn it on and apply the change. I believe it was introduced in >> Emacs 27. >> >> The idea is to save CPU by not having to look at files periodically to >> see if they have changed. I have no idea if you would see any improvemen= t >> at all, but it shouldn't make anything worse. >> >> --000000000000f1a5fd059b81f134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correction -- the "lock-up" I observed might have bee= n due to paging (possibly related to emacs - I'll have to investigate l= ater).
Toggling auto-revert-avoid-polling appeared to reduc emacs CPU usage= , according to top(1) - it's a bit difficult to tell because there seem= s to be some lag in when the command takes effect and my compilation proces= s switches a certain amount between CPU-intensive and IO-intensive. Anyway,= CPU seemed to drop from ~60% to ~30% (please take this observation with a = large grain of salt).
I'll try more things in the future and report if = anything interesting shows up.
- peter

On Mon, 6 Jan 2020 at 16:01, Pe= ter Ludemann <peter.ludemann= @gmail.com> wrote:
If anything, auto-revert-avoid-polling makes respons= iveness worse -- the window locked up a few times on me while doing ctrl-N = while running a CPU-intensive (and possibly IO-intensive) compilation.
Alth= ough I might not have set the value correctly ... I did=C2=A0M-x customise-variable RET auto-re= vert-avoid-polling RET then "toggle" then "apply".
.=

On Sun, 5 Jan 2020 at 11:57, Mattias Engdeg=C3=A5rd <mattiase@acm.org> wr= ote:
5 jan. 2020= kl. 20.31 skrev Peter Ludemann <peter.ludemann@gmail.com>:

> Which version of Emacs would you like me to try this with? And what re= sult are you expecting/hoping to see? (e.g., might it reduce the current 30= -80% CPU load for polling with emacs 28.0.50?) There are only a few open fi= les directly under /tmp, so would this have any effect or does it propagate= down to subdirectories?
>
> [Also, I'd need a few more details (not being an emacs-internals p= erson) ... should I add this to my .emacs and restart, or execute in a scra= tch buffer, or ...?]

'auto-revert-avoid-polling' is a single global customisable variabl= e, so you would set it using

=C2=A0M-x customise-variable RET auto-revert-avoid-polling RET

, then turn it on and apply the change. I believe it was introduced in Emac= s 27.

The idea is to save CPU by not having to look at files periodically to see = if they have changed. I have no idea if you would see any improvement at al= l, but it shouldn't make anything worse.

--000000000000f1a5fd059b81f134--