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: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Sun, 16 Jan 2022 17:43:19 +0200 Message-ID: <83h7a3y9d4.fsf@gnu.org> References: <83mtjwzwkb.fsf@gnu.org> <87r198ytog.fsf@gnus.org> <87lezfzy5h.fsf@gnus.org> <83sftnyilw.fsf@gnu.org> <83mtjvyd4t.fsf@gnu.org> <83k0ezyb68.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6791"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 16 16:44:54 2022 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 1n97iA-0001Xg-0M for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 16:44:54 +0100 Original-Received: from localhost ([::1]:47360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n97i8-0003O7-GY for ged-emacs-devel@m.gmane-mx.org; Sun, 16 Jan 2022 10:44:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n97gp-0002e0-II for emacs-devel@gnu.org; Sun, 16 Jan 2022 10:43:31 -0500 Original-Received: from [2001:470:142:3::e] (port=49364 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n97gp-0006qY-2w; Sun, 16 Jan 2022 10:43:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dDZFxHReHbd7bMns/D2tdmWF3itHgDcjxs5n6NRiCWg=; b=kwAN/upmfFuH Ez712tRBLd4qMxlz61O1MTghRQBi/0BoUUj9KVj8dcy75wCYzkCEufU3kIHmZ706SdGWFrHQKpgvM rJnLxIRzaL1Dgi6ztnrtllqtiLrNrndiwvMJCZoRVxSgLJW6pd2oEsv69Ob/r72u8iJGy4a/fR5xn JifRrDPqQBrC4SXC2Npkyc2zJR4l0rKFkwIbZeY4tPuTWbwgN2lcrXakuq6XU5W8fEtZ1iDLkfl/7 X8M3G7UHCbigyoxuNlBfFv7PCU4dSu476ZeGboN0cxIQ1lZ1ViPNFDyW+fKVM2BKwHbVJcbJaZqq+ EhBODLUYHQUvRGtIfv/Gmw==; Original-Received: from [87.69.77.57] (port=4588 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n97gp-0007gz-42; Sun, 16 Jan 2022 10:43:31 -0500 In-Reply-To: (message from Alan Mackenzie on Sun, 16 Jan 2022 15:26:44 +0000) 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" Xref: news.gmane.io gmane.emacs.devel:284830 Archived-At: > Date: Sun, 16 Jan 2022 15:26:44 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > I thought the slowdown was in Lisp somewhere. If it's in EQ, I'm not > > sure I understand how come the byte-compiler's slowdown is so much > > more significant than in other Lisp code. > > The specification of the macro lisp_h_EQ in lisp.h L370 starts off: > > #define lisp_h_EQ(x, y) ((XLI ((x)) == XLI ((y))) \ > || (symbols_with_pos_enabled \ > ..... > > If symbols_with_pos_enabled is currently false, EQ need never execute > more than these first two lines. If the variable is true, potentially > each of the other three cases (each variable x and y can be with or > without a position, giving four matching possibilities) needs to be > checked individually, which is slow. > > Essentially the same code is coded up as emit_EQ inside comp.c. Yes, but my question was why would this affect the byte-compiler more than it affects any other arbitrary Lisp. Are you saying that the byte-compiler is such a more intensive user of EQ than other Lisp programs?