From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Debouncing slow mode line constructs (was: Emacs design and architecture. How about copy-on-write?) Date: Fri, 22 Sep 2023 15:08:08 +0300 Message-ID: <83h6nm76mv.fsf@gnu.org> References: <838r92cgxp.fsf@gnu.org> <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> <83y1h1axtq.fsf@gnu.org> <87sf79rq5o.fsf@yahoo.com> <83fs38c2yv.fsf@gnu.org> <83o7hw9ee1.fsf@gnu.org> <87il84q845.fsf@yahoo.com> <83il849bx6.fsf@gnu.org> <87a5tfri8c.fsf@yahoo.com> <878r8z27cs.fsf@localhost> <44e98df7-f683-ac07-e644-40757f1d26f9@gutov.dev> <87msxfzts6.fsf@localhost> <7b0c07f5-88c8-4f2c-6ac6-a6112c884f32@gutov.dev> <87il83zsg1.fsf@localhost> <87fs37zrjx.fsf@localhost> <83ttrn8woc.fsf@gnu.org> <87h6nmy098.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22941"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 14:09:06 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qjey2-0005n5-4q for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 14:09:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjexJ-0000Fy-EL; Fri, 22 Sep 2023 08:08:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjexE-0000Cb-63 for emacs-devel@gnu.org; Fri, 22 Sep 2023 08:08:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjexB-0004rX-Sh; Fri, 22 Sep 2023 08:08:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+6D9Cip2mI3ZgEnbnqFKAhLVEBgBBuIMHfjYG6q/GYo=; b=rtUPtDkguQBQ VTXV2AnoBWJEf/xkkYuTWOyk6S9f1e8XWRDpRpjaSjuUHFCI/AJIeMurVZvXnvL9drLWEWVt8oIUS jjnRH7kp9vqiSHu1500gzJ9YlrmJHLtEWcM9nxARHzx7JdZTHxc73NGpDo+NhNQAMDnR+0BmfUtPg q0pxeC8gFRp1TrTvAcXopmz517TBHpjtqrfLUOvuObWteUFkRc6k8J8YASGrCaSv+7U0ezl4I1Haj 2/x7Q+BVWlR/+hXa3LGTfTt5w4ma5W8VhyiClb6MKGHk+PAwdzGaeQcPVPo+fC/mJkIpdCfhNCGEp 1wUMKk+lhDDollwaEMmzZg==; In-Reply-To: <87h6nmy098.fsf@localhost> (message from Ihor Radchenko on Fri, 22 Sep 2023 10:23:47 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310952 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org, > emacs-devel@gnu.org > Date: Fri, 22 Sep 2023 10:23:47 +0000 > > Eli Zaretskii writes: > > > How do you propose to evaluate just portions of the mode line? What > > will the :eval whose processing is bypassed yield, and how will that > > affect processing of the rest of mode-line-format, given its > > highly-recursive processing structure and the fact that the text > > produced by this processing is laid out as it is produced? > > What I have in mind is the following: > > 1. Every time Emacs processes :eval construct it (a) measures the time > taken; (b) caches return value. This needs to somehow identify each :eval and record its execution time. > 2. If the total render time exceeds configurable threshold, processing > the most time-consuming :eval constructs will be suspended until > "debounce" time since the last full processing. > > By "suspended", I mean that cached :eval value is reused instead of > invoking :eval again. Possibly, not reused verbatim, but by replacing > the cached value with some kind of placeholder that has the same > total height/width as the cached value. This needs also to cache the last value of each :eval. It also assumes that these elements are quasi-static, for long enough time to decide which one(s) are slow and reuse their cached values. But mode-line-format is just a variable, and a Lisp program can legitimately change it at a high frequency, which will defeat any useful caching (because the :eval elements change and no longer match their cached entries). Moreover, a Lisp program can decide to deliberately defeat this caching by relatively simple measures. Last, but not least, all this additional processing will make mode-line display slower even if all the :eval forms are completely benign. Also, Emacs has a tradition of leaving Lisp programs enough rope to hang themselves, as long as they don't cause crashes and other catastrophic outcomes. This proposal will prevent a Lisp program in :eval from doing its thing simply because we don't like its timing (which, btw, depends on the CPU power, so a threshold that is an absolute number of seconds is not necessarily the best idea). In some quarters, this could be seen as breaking the contract. The example with an external Git command is very relevant: using a cached value could present to the user completely misleading indications. So I think this is a lot of trouble for little gain, and could be also against our long-standing policies.