From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Excessive use of `eassert` Date: Sun, 21 Jan 2024 10:59:45 +0000 Message-ID: References: <83jzo5x0q8.fsf@gnu.org> <83sf2tv029.fsf@gnu.org> <811d5f03-fad4-47e1-b3fd-2f45229a5ee1@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 21 12:00:59 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 1rRVZR-0003GT-AL for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jan 2024 12:00:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRVYc-00034D-8M; Sun, 21 Jan 2024 06:00:06 -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 1rRVYa-00033x-GF for emacs-devel@gnu.org; Sun, 21 Jan 2024 06:00:04 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rRVYY-00031E-Dl for emacs-devel@gnu.org; Sun, 21 Jan 2024 06:00:04 -0500 Original-Received: (qmail 22659 invoked by uid 3782); 21 Jan 2024 11:59:46 +0100 Original-Received: from acm.muc.de (p4fe15af4.dip0.t-ipconnect.de [79.225.90.244]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 21 Jan 2024 11:59:46 +0100 Original-Received: (qmail 22679 invoked by uid 1000); 21 Jan 2024 10:59:45 -0000 Content-Disposition: inline In-Reply-To: <811d5f03-fad4-47e1-b3fd-2f45229a5ee1@cs.ucla.edu> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:315168 Archived-At: Hello, Paul. On Sat, Jan 20, 2024 at 17:41:57 -0800, Paul Eggert wrote: > On 2024-01-19 11:42, Alan Mackenzie wrote: > > On Fri, Jan 19, 2024 at 17:02:06 +0200, Eli Zaretskii wrote: > >> make_fixnum is a trivial bit-shuffling, whereas make_lisp_symbol is > >> much trickier. Perhaps especially so now that we have > >> symbols-with-positions as well as bare symbols. > > Not really. Symbols with positions don't belong in the obarray. If they > > somehow get there, then that's a bug to be fixed. > The problem here isn't calling make_lisp_symbol to make symbols with > positions. It's that Qnil expands to builtin_lisp_symbol (0) which calls > make_lisp_symbol (&lispsym[0]) which calls XSYMBOL, and XSYMBOL is > significantly slower now that we have symbols-with-positions, even when > it is applied to a bare symbol - and this is particularly true with > --enable-checking and the eassert Stefan mentioned. > I looked into this a bit and installed the attached patches which should > speed things slightly even with a default build. The main goal was to > speed up debugging builds, though. I don't think the first patch is correct. With it applied, the code no longer signals the error of a symbol with position being processed when symbols_with_pos_enabled is false. That's in the debug build, of course. The second patch seems OK. > When I built with --enable-checking this seemed to help significantly on > Ubuntu 23.10 x86-64 with GCC 13.2 -O2 (at least looking at the machine > code; I didn't benchmark). This depends on compiler and platform so it'd > be helpful if Stefan could try it out on his machine and see whether it > helps his cases' performance. The "significantly" here means the 0.4% speed up in the default build that you mention in the first patch, does it? -- Alan Mackenzie (Nuremberg, Germany).