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: Redisplay slower in Emacs 28 than Emacs 27 Date: Tue, 08 Dec 2020 17:50:29 +0200 Message-ID: <83im9c70vu.fsf@gnu.org> References: <877dptiro7.fsf@gnus.org> <87pn3lhcdd.fsf@gnus.org> <878sa9hbe2.fsf@gnus.org> <877dptfvae.fsf@gnus.org> <83czzl8qwu.fsf@gnu.org> <87sg8h78s8.fsf@gnus.org> <837dpt8lk5.fsf@gnu.org> <87pn3kjssr.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 08 16:52:52 2020 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 1kmfIK-0009S8-1V for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 16:52:52 +0100 Original-Received: from localhost ([::1]:53690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmfIJ-0003Em-4r for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 10:52:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmfGG-0002TV-KD for emacs-devel@gnu.org; Tue, 08 Dec 2020 10:50:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52780) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmfGC-0003yk-FM; Tue, 08 Dec 2020 10:50:43 -0500 Original-Received: from [176.228.60.248] (port=2756 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kmfG8-0003e5-2G; Tue, 08 Dec 2020 10:50:40 -0500 In-Reply-To: <87pn3kjssr.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 08 Dec 2020 15:06:44 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:260561 Archived-At: > From: Lars Ingebrigtsen > Cc: ghe@sdf.org, emacs-devel@gnu.org > Date: Tue, 08 Dec 2020 15:06:44 +0100 > > But before doing that, we should probably decide, once and for all, > whether the cache should be on spec equality or identity... > > And if we really go with identity (which we do now, but... wrognly), we > could go one step further, and just look at the identity of the spec > itself, instead of looking at the identity of the contents. > > That is, use > > && EQ (img->spec, spec) > > instead of > > && equal_lists (img->spec, spec) I think using EQ might break something, given that we've been using Fequal for a long time. > Or, if we decide to revert to a more permissive cache again, we could > just go back to using > > && !NILP (Fequal (img->spec, spec)) We could do that, yeah. But most of the members of an image spec are symbols and suchlikes, so maybe we could use EQ for almost all of them, except for strings?