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: Sat, 4 Apr 2020 10:45:53 +0000 Message-ID: <20200404104553.GA5329@ACM> References: <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@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="98078"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 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 Sat Apr 04 12:47:07 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 1jKgKQ-000POq-SM for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 12:47:06 +0200 Original-Received: from localhost ([::1]:37422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKgKP-00086a-VC for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Apr 2020 06:47:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40593) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jKgJN-0007Wa-UX for emacs-devel@gnu.org; Sat, 04 Apr 2020 06:46:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jKgJK-0004KW-1u for emacs-devel@gnu.org; Sat, 04 Apr 2020 06:46:01 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:47858 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jKgJJ-0004IJ-Oh for emacs-devel@gnu.org; Sat, 04 Apr 2020 06:45:58 -0400 Original-Received: (qmail 73084 invoked by uid 3782); 4 Apr 2020 10:45:55 -0000 Original-Received: from acm.muc.de (p2E5D54F1.dip0.t-ipconnect.de [46.93.84.241]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sat, 04 Apr 2020 12:45:53 +0200 Original-Received: (qmail 5338 invoked by uid 1000); 4 Apr 2020 10:45:53 -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:246383 Archived-At: Hello, Martin. On Sat, Apr 04, 2020 at 10:56:27 +0200, martin rudalics wrote: > > This assumption proved to be very problematic. The fact is, people put > > parentheses in column zero inside comments, and nothing we can say or do > > will stop them. Why should it? these parentheses are perfectly valid > > in so many languages. Most notoriously was bug #22884, where there were > > such parentheses in Emacs's own C sources. And there were quite a lot > > of ostensible bugs in CC Mode caused by these parentheses. > All these problems could have been cured easily: People who want such > parentheses would have set 'open-paren-in-column-0-is-defun-start' to > nil (or used a default value of nil) and everybody would have been > happy. But throwing out the child with the bathwater by eliminating the > effect of that variable completely has left us no clue as to what makes > scrolling so slow in the present situation. Well, there aren't "people who want such parentheses". They just happen, without any conscious decision on the user's part. Maybe, as you say, changing o-p-i-c-0-i-d-s's default to nil would have been better. But I'm a bit puzzled by the "scrolling so slow" bit. [ .... ] (I hope to get around to commenting on the rest of your post, sometime.) > I already cited the scrolling example in my other posts. Scrolling > dispextern.h and xdisp.c each take 10 seconds for one turn of the wheel > and consume 100% of the allotted CPU here. There's something very strange going on, here. If I do (time-it (scroll-up) (sit-for 0)) in a region of xdisp.c where the next screenfull hasn't yet been fontified, it takes 0.029s on my machine. For you it's taking 10s. That's a factor of ~350. Even taking into account me running on an optimised build, and you (presumably) on a debug build, that gives a factor of ~100 difference. I appreciate you needing to run in a debug build, but what sort of timing do you get on an optimised build? I think you said you have a state of the art 2007 processor. Mine is from 2017. Processing power did not speed up by a factor of 100 in that period. There is something very strange happening here. [ .... ] > I still don't understand why it > [open-paren-in-column-0-is-defun-start] had to be eliminated. > Defaulting it to nil but respecting a non-nil value would have been > completely sufficient IMHO. Maybe we didn't have your benchmark at the time the change was made, which I think was around 2015. > martin -- Alan Mackenzie (Nuremberg, Germany).