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 20:36:47 +0100 Message-ID: <87y2i89jjk.fsf@gnus.org> References: <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> <87im9cfeej.fsf@gnus.org> <837dps6xyv.fsf@gnu.org> <87czzkdx57.fsf@gnus.org> <83v9dc5he3.fsf@gnu.org> <87r1o0chk9.fsf@gnus.org> <83tusw5g5o.fsf@gnu.org> <87360gaz7o.fsf@gnus.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="17715"; 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, Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 08 21:37:55 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 1kmjkA-0004U7-5F for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 21:37:54 +0100 Original-Received: from localhost ([::1]:44868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmjk9-00040s-1w for ged-emacs-devel@m.gmane-mx.org; Tue, 08 Dec 2020 15:37:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kminE-0007On-Tu for emacs-devel@gnu.org; Tue, 08 Dec 2020 14:37:00 -0500 Original-Received: from quimby.gnus.org ([2a01:4f9:2b:f0f::2]:45476) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kminA-0005la-CR; Tue, 08 Dec 2020 14:37:00 -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=QZf+ynvEVPVrGlv1grEgippfscRgBkYWw+imbb695IY=; b=pyjQXzHXO3vGXRf0jpCbzn0APk WAs78rwXiZuZphi6n84c1f56wptMnlXQBEplmha7rgZRn+GXBdd1EIz/Ib+9iW3smTJttcmsxTHAe O0YjTFgblcymt1Nnf+Audfkhh7vO5iLYmA9rhMjpP0PLcicmX9gELvc2qdg0PrjueugA=; 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 1kmin2-000770-Nz; Tue, 08 Dec 2020 20:36:51 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEXJ1+erqrFSMi+l WjLGklP///9E2Y0HAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+QMCBMhC0Ro55gAAAG6SURBVDjLpZPh seIwDIRjuAKsmALOkgsglgt4weq/pls5hGR48Os8AzPoQytpLU/Tf5+Qv8Qrx4+gCi+f4jPjxC8g 335+g6tnUPkNLg5m/lbkEwhCeT6PEuKFYgxTpFnmlU7i95mFhSjNrJzuJ4kh3lpFv0nlmGXE+f4A WJLpz1s7WSHEZn19A1wBxFTfpKTDRM6kR8JUBxDUkHh2MWxKgvvgFwj0KsGeuV9IaL3FHYxCW0bo rcuyA6ncbBsiiaK9xxM0fCyPlFpqM627zAAUfS20Ks4GCjLF8oR2rpXNQes+djHAzvcQAeAApASw a7Eq7cEZ4MKq1r0G5EQMp/JCAZPJUUIq4g/EiaaEv3lcNyCeC7D4Jo0fZggX71p0TciAewqrCy6n jA7QfEu+J1tCQ0sNOU1Vqi6+Jl0H6NZR4ZkyNu6PK4m7MoJr9z1xc9No1H82a90tkOom0jaCfzuA PVYH8DZZ83AQnVmH4tjdm1vA0QdwB6yj3vNm4QFmRcWre+WmPe+cZl8liz5rgRTXfUsAVhqXRhDu B5joRrS91aANYn9f60bL/oooCZ3fMx2vK06f3vnp0Jf4P52QagH1L9SbAAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIwLTEyLTA4VDE5OjMzOjExKzAwOjAwbM75vAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy MC0xMi0wOFQxOTozMzoxMSswMDowMB2TQQAAAAAASUVORK5CYII= X-Now-Playing: Kiko Dinucci's _Rastilho_: =?utf-8?Q?=22Olod=C3=A9=22?= In-Reply-To: <87360gaz7o.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 08 Dec 2020 20:12:59 +0100") 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:260580 Archived-At: Lars Ingebrigtsen writes: > However, if we continue using equal_lists (which compares list members > with EQ), we can write a new hash function for image.c that just uses > identity/number values of the elements, and we'd get a nice speed-up. Here's a stab as a new EQ-ey image spec hashing function: diff --git a/src/fns.c b/src/fns.c index e4c9acc316..2512bce5f5 100644 --- a/src/fns.c +++ b/src/fns.c @@ -4640,9 +4640,48 @@ sxhash_bignum (Lisp_Object bignum) } +EMACS_UINT +img_hash (Lisp_Object spec) +{ + EMACS_UINT hash = 0; + + while (CONSP (spec)) + { + EMACS_UINT val; + Lisp_Object obj = XCAR (spec); + spec = XCDR (spec); + + switch (XTYPE (obj)) + { + case_Lisp_Int: + val = XUFIXNUM (obj); + break; + + case Lisp_Symbol: + val = XHASH (obj); + break; + + case Lisp_String: + val = (EMACS_UINT) SSDATA (obj); + break; + + case Lisp_Float: + val = sxhash_float (XFLOAT_DATA (obj)); + break; + + default: + val = 0; + } + + hash = sxhash_combine (hash, val); + } + return SXHASH_REDUCE (hash); +} + /* Return a hash code for OBJ. DEPTH is the current depth in the Lisp structure. Value is an unsigned integer clipped to INTMASK. */ + EMACS_UINT sxhash (Lisp_Object obj) { diff --git a/src/image.c b/src/image.c index 5eb4132295..4c586853d8 100644 --- a/src/image.c +++ b/src/image.c @@ -1634,6 +1634,7 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash, && (ignore_colors || (img->face_foreground == foreground && img->face_background == background))) break; + return img; } @@ -1649,7 +1650,7 @@ uncache_image (struct frame *f, Lisp_Object spec) can have multiple copies of an image with the same spec. We want to remove them all to ensure the user doesn't see an old version of the image when the face changes. */ - while ((img = search_image_cache (f, spec, sxhash (spec), 0, 0, true))) + while ((img = search_image_cache (f, spec, img_hash (spec), 0, 0, true))) { free_image (f, img); /* As display glyphs may still be referring to the image ID, we @@ -2346,7 +2347,7 @@ lookup_image (struct frame *f, Lisp_Object spec, int face_id) eassert (valid_image_p (spec)); /* Look up SPEC in the hash table of the image cache. */ - hash = sxhash (spec); + hash = img_hash (spec); img = search_image_cache (f, spec, hash, foreground, background, true); if (img && img->load_failed_p) { diff --git a/src/lisp.h b/src/lisp.h index 416c9b0cac..4ca5aeced1 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3595,6 +3595,7 @@ #define CONS_TO_INTEGER(cons, type, var) \ extern char *extract_data_from_object (Lisp_Object, ptrdiff_t *, ptrdiff_t *); EMACS_UINT hash_string (char const *, ptrdiff_t); EMACS_UINT sxhash (Lisp_Object); +EMACS_UINT img_hash (Lisp_Object); Lisp_Object hashfn_eql (Lisp_Object, struct Lisp_Hash_Table *); Lisp_Object hashfn_equal (Lisp_Object, struct Lisp_Hash_Table *); Lisp_Object hashfn_user_defined (Lisp_Object, struct Lisp_Hash_Table *); -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no