From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 6 Apr 2020 19:36:33 +0000 Message-ID: <20200406193633.GD7100@ACM> References: <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200405111623.GB5049@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="92978"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at, rrandresf@gmail.com, Stefan Monnier , eliz@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 06 21:37:15 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 1jLXYZ-000O5s-8O for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 21:37:15 +0200 Original-Received: from localhost ([::1]:37522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLXYY-0006Cn-70 for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 15:37:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54986) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLXXz-0005P1-S1 for emacs-devel@gnu.org; Mon, 06 Apr 2020 15:36:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLXXy-0002tJ-Mk for emacs-devel@gnu.org; Mon, 06 Apr 2020 15:36:39 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:64722 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jLXXy-0002s4-DT for emacs-devel@gnu.org; Mon, 06 Apr 2020 15:36:38 -0400 Original-Received: (qmail 78523 invoked by uid 3782); 6 Apr 2020 19:36:36 -0000 Original-Received: from acm.muc.de (p4FE15D4F.dip0.t-ipconnect.de [79.225.93.79]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Apr 2020 21:36:35 +0200 Original-Received: (qmail 11669 invoked by uid 1000); 6 Apr 2020 19:36:33 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:246561 Archived-At: Hello, Dmitry. On Mon, Apr 06, 2020 at 17:55:50 +0300, Dmitry Gutov wrote: > On 06.04.2020 05:36, Richard Stallman wrote: > > If and when such a mechanism is in place for us free software > > activists, we might agree that open-paren-in-column-0-is-defun-start > > is not worth while any more. But it appears that has not happened > > yet, so I think that the open-paren-in-column-0-is-defun-start guided > > heuristic IS still worth while for us. > This question (whether syntax-ppss is "too slow") was raised a couple of > times already, but in all previous discussions, as well as in this one, > nobody has done the bare minimum research (e.g. profiling some > real-world scenario) to prove this claim. Nor, if it indeed showed up in > profiler reports, examined which part of the current mechanism is the > bottleneck. Nor tried to fix that part somehow. > This is not how we should approach performance problems. > The only arguments I see are nostalgic (e.g., somehow, Emacs was faster > years ago, maybe? the files were smaller, and the C standard was simpler?) I've attempted to simulate one of Martin's scenarios, and set up my tty frame with two side by side windows, each 65 lines deep and wide enough for xdisp.c not to need continuation lines. xdisp.c is displayed in both windows, from Line 401 at the LHS, and from Line 35162 on the RHS. In the LH window point is at BOL 435 (the opening brace for function fill_column_indicator_column) and in the RH window point is at BOL 35159 (a random line in start_hourglass). With various combinations of the pertinent variables, I run (time-it (insert "{") (other-window 1) (insert " ") (other-window 1) (sit-for 0)) . After each such timing I undo the buffer changes before the next timing. Here are the results: open-paren-in-column-zero-is-defun-start nil t comment-use-syntax-ppss nil 0.319s 0.264s t 0.319s 0.227s . Bearing in mind that c-u-s-p being t suppresses the action of o-p-i-c-0-i-d-s in back_comment, but not in beginning-of-defun, it seems like the o-p-i-c-0-i-d-s mechanism does indeed speed up some scenarios in C Mode, significantly but not massively. IMAO, It would be nice to have the code testing o-p-i-c-0-i-d-s (both places) able to ignore spurious cases of parens in literals. -- Alan Mackenzie (Nuremberg, Germany).