From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Redisplay slower in Emacs 28 than Emacs 27 Date: Tue, 08 Dec 2020 17:31:16 +0100 Message-ID: <87im9cfeej.fsf@gnus.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> <83im9c70vu.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="10176"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: ghe@sdf.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 08 17:38:03 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 1kmg03-0002WK-Kl for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 17:38:03 +0100 Original-Received: from localhost ([::1]:51472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmg02-0003kf-8l for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 11:38:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmfti-0008G6-BW for emacs-devel@gnu.org; Tue, 08 Dec 2020 11:31:30 -0500 Original-Received: from quimby.gnus.org ([2a01:4f9:2b:f0f::2]:42930) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmftd-0002GJ-9D; Tue, 08 Dec 2020 11:31:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VlTsJfZ8ttAcSZyXpf2LvVrgTdGEs1htlHZfSDqHcbc=; b=PI+tDbZ0T1txS2ZOM3MnN9SGoN Q/i28f4n9QHm5XCkVIPjNo1EZoS5fR3EEDJkIoYD0Zd2Qgpz7+lNiXNOJ6rsoLQBDV9EjuMMQyDGM C92eJA0B6Dsn2TOwd4tkfY91GcpcAirka005n/W+f8hpVjDB48kSiFejN24cEutq6BWo=; Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kmftV-0004dz-So; Tue, 08 Dec 2020 17:31:20 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU2JyqVhpHKNiD/ //9bUqJDAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+QMCBARBX7QQjUAAAFvSURBVCjPTdK/TsMwEAbw z1EshUyNRBmYKqbip3AkG6lMLYo9dGNAonmKiIEhEwxlNkhYyT0l5/QPvSX66S7nz1Ewp/+CvISm /c57/zXSwJ2wfhEPD5tnDQUR142wOqGEiR8GTVNtNG7h4j6HlVWVOlXc5DBiI8GYxc9a2LoSqaPj h3Z5UyF1bmKHY5XwMWRnPMUh6xbA9M5TpGV3V5SLw9gh5PcE6ntCUEhjNGRvBUI5LaAAFABvXDDO xywZmtc6GFjPWOdSChhtfc+4lrmozdrcMExV5cKZxvpHjGY1M+LVWGsZdjU3YmesyRhyt7WM2vCh YxzbnSOnpebVU9DhrpviJAzI/sFhwgn87MLygAEgCs6rI75i2HsCvfONyttL8Nj+54j7Fwrxp0fb 812vftuguNO+M8rVAEVHZH1gtGh/HZ+vsMhSZwpTFHJ7Rip1xqzmTAn8QUtbp/+gpSEFHWsnT/MZ dXN3QqpcXQDqDx9Oqg61N4v0AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIwLTEyLTA4VDE2OjE3OjA1 KzAwOjAwItwRvwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMC0xMi0wOFQxNjoxNzowNSswMDowMFOB qQMAAAAASUVORK5CYII= X-Now-Playing: =?utf-8?Q?R=C3=B3isin?= Murphy's =?utf-8?Q?=5FR=C3=B3isin?= Machine_: "Incapable" In-Reply-To: <83im9c70vu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Dec 2020 17:50:29 +0200") Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, 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.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:260567 Archived-At: Eli Zaretskii writes: >> 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. Yeah, the equal_lists thing did break the toolbar cache, so there might be other breakages. On the other hand, it seems like it didn't break much else, so we might want to continue in this direction to make redisplay of images faster. And moving to just EQ is one more step in that direction. >> 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? Fequal is already pretty optimised, so in practice, it isn't that different, really. Its uses EQ for symbols and stuff, and I think it compares strings with EQ first, and only looks at the contents of the strings if they aren't EQ? Or do I misremember? So moving to Fequal is fine if we decide to have the Emacs 27 caching semantics. However, if we move to EQ semantics, the real speedup is that we don't have to call sxhash(img) on all the images -- and that's a slow operation, because it'll call hash_string on all the string contents, and if you have a large :data image, it'll compute that every time Emacs decides to redisplay that image. My proposal is: Be explicit in documenting how images are cached, and only cache images based on EQ-ness of the spec. That will speed up redisplay of large :data images substantially (since we never need to do an sxhash on the spec). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no