From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Improving EQ Date: Thu, 12 Dec 2024 08:36:50 +0000 Message-ID: <871pydjo23.fsf@protonmail.com> References: <87h679kftn.fsf@protonmail.com> <86frmt1k6w.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2825"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= , Paul Eggert , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 10:19:34 2024 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 1tLfM2-0000TA-Es for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 10:19:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLfLb-0002wd-I4; Thu, 12 Dec 2024 04:19:03 -0500 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 1tLegt-0000uk-W0 for emacs-devel@gnu.org; Thu, 12 Dec 2024 03:37:05 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLegr-0005sw-9G for emacs-devel@gnu.org; Thu, 12 Dec 2024 03:36:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733992613; x=1734251813; bh=Ak6nUm5HUbPdF1QZpe92KaKvegMN2jGbL0j6FGlUclY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=KQ4fGr8bKrA+YTbZHM0sTSFgTtCPwxjIfZCvNhb9yy54spZz/sC9dKsat9OYSzisY yANkjdakMtZ2xDrsocCm73iFh/Pw54kIMSXuIxzgz34QBCiIUhV04AL7NU8T6pKNiu W0nhbcu7FYIIyXMS6/oaiTgXPPAkMtvyU0+JBOvPeRufoIvAxQhenUwnCNpOlHpWNP smr2mk+o2b6c3700mnfcfSCQoW3xDomIaUuuTSWzCQubXzg9im/Jg4fo5cZnRWkaWd S73x/1FkKk1iTi5178BMODxwunCJ/1AkjaD6AhK39Ty6GLkoNSmeg1TrlHJtJd/sa2 Slcb9dHhjZyrw== In-Reply-To: <86frmt1k6w.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 54693734a40aecf9c4e333ea600260103d02bbbe Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 12 Dec 2024 04:19:00 -0500 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:326414 Archived-At: "Eli Zaretskii" writes: >> Date: Wed, 11 Dec 2024 22:37:04 +0000 >> From: Pip Cet via "Emacs development discussions." >> >> What's missing here is a benchmark, but unless there's a really nasty >> surprise when that happens, I'm quite confident that we can improve the >> code here. > > The usual easy benchmark is to byte-compile all the *.el files in the > source tree. That is, remove all the *.elc files, then say "make" and > time that. Considering the point of the optimization was to make compilation (when symbols_with_pos_enabled is true) slower, but speed up non-compilation use cases, I think that may be the opposite of what we want :-) Furthermore, the master branch doesn't currently build after deleting all the *.elc files, because recompilation exceeds max-lisp-eval-depth in that scenario (together with the known purespace issue, this pretty much means "make bootstrap" is the only way I can rebuild an emacs tree right now. It'd be great if Someone could look into this, but I've failed to understand the native-compilation code (and been told off for trying to) too often for that Someone to be me. Plus, of course, I fully understand that native compilation currently has wrong code generation bugs which obviously have to take priority over build issues...) > There was also some Emacs benchmark suite that someone posted, but I > cannot find it now, maybe someone else will. https://elpa.gnu.org/packages/elisp-benchmarks.html ? It'd be great if we could agree on a benchmark, and even better if there were a way to reliably run it from emacs -Q :-) In fact, I would suggest to move a reduced benchmark suite to the emacs repo itself, and run it using "make benchmark". Also, just to let everyone know, I'm planning to make the "exotic" property (this object must or can use the slow_eq path) part (probably the LSB) of the tag rather than accessing it via a global variable and the PVEC type. This should reduce code size further, should speed up things, and has some other advantages which I'll go into when I have working code. Pip