From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Fri, 03 Apr 2020 12:56:01 -0400 Message-ID: References: <86tv2h2vww.fsf@gmail.com> <20200322123818.GB32470@ACM> <87eetk5swm.fsf@gnu.org> <20200326193128.GC14092@ACM> <86d08y4zsx.fsf@gmail.com> <83sghs7qdz.fsf@gnu.org> <83h7y63sjj.fsf@gnu.org> <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <29a6c120-f260-0ea3-f5e0-1d3dd6323d09@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="69747"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: acm@muc.de, eliz@gnu.org, rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 03 18:56:42 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 1jKPcY-000I0Z-IB for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 18:56:42 +0200 Original-Received: from localhost ([::1]:58416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKPcX-0005JG-Jx for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Apr 2020 12:56:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41658) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKPc1-0004pj-EH for emacs-devel@gnu.org; Fri, 03 Apr 2020 12:56:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKPbz-0006rO-Mb for emacs-devel@gnu.org; Fri, 03 Apr 2020 12:56:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59682) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jKPbx-0006ot-RU; Fri, 03 Apr 2020 12:56:06 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CBDF310031F; Fri, 3 Apr 2020 12:56:04 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 295A51002FC; Fri, 3 Apr 2020 12:56:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1585932963; bh=Wz6VxEsSkEb4gj7bdHP5pugdYHNUW4tSI8qpVyemwE8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RtFxOgl3B93TsyyNcGy6Hl3q1g9y9XZ/XI/EMiUHluPRT8dmubbkmB/LqwnAkWmoq /SgkplH4SoyAYv9tWKjiT7PIqJpextedlepai6FefMc1OFUxZSnyeH9bH83szcuTok OU1R3kugmokXhkUgeiJj74ybm6iSkIs3CTJJGBl+9Ur8AaTxOLMAfIS79tCZjcjeW9 vv10pdcqJZDylr7P8OwWWmAD8IBy/SV56sNv8wU8vhyhJMDdKuDv4Ka0Lc5Tsj605g fXfsUeFF1SWkAsDjbWLnwazjvrKuIx3iIVyQfF/Sro5hnJZxD6CdZXHnoaSJ/2If76 3l2j8DFX2VqZw== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B33512030B; Fri, 3 Apr 2020 12:56:02 -0400 (EDT) In-Reply-To: <29a6c120-f260-0ea3-f5e0-1d3dd6323d09@gmx.at> (martin rudalics's message of "Fri, 3 Apr 2020 18:23:26 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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:246339 Archived-At: >>> The basic slowness of Emacs over the past years is a direct consequence >>> of that policy. >> Do you have some kind of (concrete, statistical, circumstantial, ...) >> evidence for that? > I'd gladly provide such evidence to prove or disprove my claim. I understand proving/disproving it is hard. I'm really asking what are the signs that make you think it's due to the lack of use of `open-paren-in-column-0-is-defun-start`. > But customizing 'open-paren-in-column-0-is-defun-start' has no effect > here any more and reconstructing its earlier semantics would consume > more resources than I can afford. Yes, I don't think there's much interested in going back to that. OTOH if we could find specific cases where the old code was faster (supposedly due to its use of `open-paren-in-column-0-is-defun-start`), we could think about how to recover that performance. E.g. `open-paren-in-column-0-is-defun-start` was used in `forward-comment` was scanning comments backward to avoid having to use `parse-partial-sexp` all the way from `point-min` in the worst case. We replaced that with a parse cache (`syntax-ppss`) which seems to be just as good in my experience (and significantly better in those languages where open parens in column 0 are virtually non-existent). If we can show that this replacement is not "just as good", there are various options to improve it or replace it, but we'd need to know which case(s) matter in order to design it. Stefan