From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 16:03:05 +0300 Message-ID: <87r0mqweba.fsf@localhost> References: <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> <83h6nm76mv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18119"; 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: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 15:02:39 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 1qjfnq-0004W5-Uu for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 15:02:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjfnK-0004hY-GH; Fri, 22 Sep 2023 09:02:08 -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 1qjfn9-0004bZ-SB for emacs-devel@gnu.org; Fri, 22 Sep 2023 09:02:00 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjfn6-0000y2-TQ for emacs-devel@gnu.org; Fri, 22 Sep 2023 09:01:55 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1D6C4240103 for ; Fri, 22 Sep 2023 15:01:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695387711; bh=RrQmSqlM+aW7JJdpgcxUbalbWIwllkgXNC/Z1c+m2Hc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=bxRD3BeBrUMm4PP07/tfZ95ZL5v4IZWoC4/MCG8qZYNLxE1eZwxGYD+p1J+ckiLOL c3pGa4PtI4qh/zgt7U6Gj8h9q97HdxDgZqAeM/CoerZa1M1tRa812nfrRG3jACjoNS tJasoySM6DiiumcfYeYK3rG6Z7I+IEPF7Ua0ZaQs/SwsEPp19L4Q5bWSqyaLxFTA5A p9d4usDpSLezQxWB+yAmGxhlNO+D9rblDtWMls/PWSDQ8AMhy5/7XXMS/IorXEtVhS FuZbtg+re1jVazEE3ouIRcpmedOS1p14eElvf88Rlk8V/HTaBsqEO2hFRyp77VT/+9 ZWS+DovBYraFA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RsXTp153Fz6v69; Fri, 22 Sep 2023 15:01:49 +0200 (CEST) In-Reply-To: <83h6nm76mv.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:310960 Archived-At: Eli Zaretskii writes: >> 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. Just sxhash, for example. >> 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. Yes. > 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. You are right. Such assumption may or may not hold. Though nothing prevents us from deciding based on running average of several previous :eval processing times instead of just one previous time. > 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). Sure. Though I am not aiming to solve such scenarios. IMHO, they are not very common. > ... Moreover, a Lisp program can decide to > deliberately defeat this caching by relatively simple measures. I see no reason to prevent that if it is deliberate. The point is that Lisp program will declare that "yes, I know that mode line may be slow" by doing such thing. Which should be totally fine as long as it is the decision made by the Lisp program author. > ... Last, but not least, all this additional processing will make > mode-line display slower even if all the :eval forms are completely > benign. Maybe. But we can try and see if it is actually going to be the case. > 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. IMHO, long-line-threshold, for example, is also breaking the contract you are referring to. So, if we leave legitimate ways for a program to bypass this optimization when necessary, it should not be a problem. > 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. Well. Strictly speaking, current Git branch may not be up-to-date even without my proposal. Simply because Emacs gives no guarantees about how frequently the mode line is refreshed. redisplay optimizations may decide to not refresh the mode-line when typing. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at