From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Sun, 07 Aug 2022 19:02:55 -0400 Message-ID: References: <6ae35c9306ade07b4c45@heytings.org> <835yj4xhh7.fsf@gnu.org> <83y1w0w0gk.fsf@gnu.org> <83pmhcvugm.fsf@gnu.org> <651cad2f-3ce3-22dd-0829-38dd3c46ec40@yandex.ru> <83o7wwvsqf.fsf@gnu.org> <83lerzx5m1.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="27903"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Dmitry Gutov , acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 01:05:32 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 1oKpKu-000702-06 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 01:05:32 +0200 Original-Received: from localhost ([::1]:51816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKpKs-0002wa-T5 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 19:05:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKpIW-0000ol-Ep for emacs-devel@gnu.org; Sun, 07 Aug 2022 19:03:04 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30007) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKpIT-0003Qn-OQ; Sun, 07 Aug 2022 19:03:03 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D79F88076B; Sun, 7 Aug 2022 19:02:59 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B5BDF80323; Sun, 7 Aug 2022 19:02:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659913378; bh=nZtXBWI7JK6bp4BMktz3o2lT+oTeW/+iTAB1jelZOHM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hELXInOu/gEO1HIV/bGD1JKau+payCTiH/U4X3dqgqH8LlXYZAIHC+Uc56kNPEi/p cECab6F5zGKz3ocevyrpvh2Pqt5tyRi5kgrA57CwCYhhbeYRcCS7p2BBNFBU6OoEtI OGvfgWCT2zdHhcCErnf1/KQtalQaybU81L7NWmHOBg6+cFhzA2ashkttL83mSgOBf7 meHa5WARacZr62w25aYwLRy4r2VgRgJqZFUfXOayB6d/KmJbT1lQXii+pJfmOxz2uF hecTZw5G5q1ujjKYBOFuWc1vp2r57/2IucsxnsbixDY75/kxzwPYIJ7qmO4N/mSMBK /bO+kugvpP9og== Original-Received: from milanesa (dyn.144-85-181-035.dsl.vtx.ch [144.85.181.35]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB8B71201F4; Sun, 7 Aug 2022 19:02:57 -0400 (EDT) In-Reply-To: <83lerzx5m1.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Aug 2022 21:37:10 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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" Xref: news.gmane.io gmane.emacs.devel:293237 Archived-At: >> The more than 10x difference in performance is weird, though. Perhaps >> you have any ideas why parse-partial-sexp's implementation might behave >> poorly on your un-optimized build? Some tweak in the code might make a >> lot of difference. > > I hope Stefan could do something about it. Not sure I can be of help. Over the last few years we've had a few times some significant performance regressions in the unoptimized build, typically because of code cleanups that replace macros with inlinable functions or things like that, where the optimized build usually doesn't suffer (or even gets faster) which the unoptimized build can be significantly impacted. Way back when, an unoptimized build was not terribly slower than a -O2 build, but our current coding style in src/*.[ch] tends to make that difference much larger. The last few times we saw that, Paul has been quite good at finding a few culprits and tweaking the code so that the overall impact is brought back down to something acceptable. Stefan