From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Mon, 6 Apr 2020 11:05:11 +0200 Message-ID: <1ac21874-3068-0c58-ce73-3a7297e67823@gmx.at> References: <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200404104553.GA5329@ACM> <07fe3b69-3ab2-3173-0696-cb17809e2b91@gmx.at> <83blo7v68b.fsf@gnu.org> <1845d7aa-9ae4-3d95-6a30-c7b1d8d8adec@gmx.at> <83a73qt6zs.fsf@gnu.org> <97c4254e-ff43-8402-3645-f713c408c245@gmx.at> <83y2r9syby.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49514"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 06 11:13:18 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 1jLNoj-000CmM-PU for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 11:13:17 +0200 Original-Received: from localhost ([::1]:56628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLNog-0003I6-Ns for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 05:13:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39943) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLNhJ-0000KB-S6 for emacs-devel@gnu.org; Mon, 06 Apr 2020 05:05:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLNhC-00013u-GV for emacs-devel@gnu.org; Mon, 06 Apr 2020 05:05:37 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:41429) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLNgx-0000w6-Ey; Mon, 06 Apr 2020 05:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1586163912; bh=I1RB2BK2kw/ogLtzg8XtMaI+LBdwxl6TCp6KxNos/x0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Ttysm0/mDTRkCzKiUWcfHWJNdiEPwl/er2ca5hAH60efpO6dMaxA3MZoZHpWXxHuY gjxUD9lKDf+C4ofWmahmRMAxbXzSTnD00XhjbAkBGv1++dT9fEMaQ/h2aZ7+I/I365 RweBiPCO44O81gj4UerAfiUhW2XgLO5Ov6F4EYdk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.102]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MowKi-1ixYfx49mQ-00qRXt; Mon, 06 Apr 2020 11:05:12 +0200 In-Reply-To: <83y2r9syby.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:zUpkZeHOvhxcBGv99nnZwt6JXXMaXzSAeKCPs/sb0EabSLJVQRa /723lD8mnvS522gU4ofvc4rVuzp7V/Y4ZQl5ANSDsaQ7FJJSTtb34yUpaYSl2E5aPGhDM14 xlxxis9Dh2yEorT6lzKJf0uI6CqNBz/tGfklZmkSha249JciOZE0Y0aMBMDnFFwwmK8pKiy RUEq5dGT5hd2uqshjQVbw== X-UI-Out-Filterresults: notjunk:1;V03:K0:hafp/u29CDI=:QZgQ+17YPPJl9vFfSmf0S0 jGXgTtaGghTw5IG6DQa9Yoj1wyrTnw4ZOdAfEB0XPRj0lq/2GlS72i6kxlFCoI/UAL9Me6/rS mFmTGPbjHT5+cBG0Qs19Vuo2hRppq8Dh5mvVyx4SLvZvJXDVd012te556EeZIIxVLP8wImsHi QfPrcD0rDvAOnpF6QWvKxP9uPEHyui3aPjw+qIuI3D4EVrxXHdev0TZkBt+eRDTmhADl3yTBL 6lv3hZsV0bK67Jqs3HLfCU27jYUrLQQIJ+mSdkEARj7wQAg33S02aF4E2LxbTW15p6oCQn5eW fIteGCURh5GhRoYwczqmr96fY7XfQCSx0hdRekutX0iaurGd5NbtMU4cjzEK6VeUFzf4Y58i3 kIboWTIOkJfMsjJKPsEr/RTqhsRS3/+euAEUnrl9TmAizOykOxulxIL5K6i3QhSMLDFn2yr1r A0CDIB4Jcfs+1OjB92ANyRuX3tCe+sPBLhSb9RN16HFWMC+dHGYipVaIbeteo9oXq3hlhvo0m le7Jr6YeMZ3OKa0jPitiUGj7GA2jFOcxdSR0hBDmAV7YBKMFe/R0DRCGFruqKiPDkHjV+kUKC wRfxdEWp1/xyLR6/xwlS9VLkssMof/gGKu7CM6Ck7bE4rVei77J/42xayIV1MlFWGOWDesD99 /Qy4Qnb32mKuAQe7DDPjoLbiRaWELKw3P5XzBbxYHcRvlKgbSfaTBr+0EGHFzTQKKM4DWKVxS G4hmxXhuLkDFIGzzpsmM9E90CaFYBAcp7793e6jGE/wa7ZO37gh7trzQAMYiIJQWekUY03xh X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:246511 Archived-At: >> I cannot nearly simulate the problem using a simple loop that steadily >> invokes say (forward-line 50) followed by a (sit-for 0). 50 such >> invocations take 16.7 seconds here, 22.7 with (forward-line -50). And >> redisplay takes place as expected here. So it's likely the mouse wheel >> input mounting up that inhibits redisplay. > > Not forward-line, scroll-up. That's what wheel.el calls. I know. But I wanted to not relate the behavior to things like the window configuration. >> Do you at least see CPU activity significantly go up when you do such >> mouse wheel scrolling? > > With what build? With the -O0 build with --enable-checking, I don't > need the mouse: it's enough to lean on C-v and let the keyboard > auto-repeat do its job -- one execution unit of the CPU maxes out > after 5 to 10 C-v's. OK. Then people see the problem and it's just that they do not build with -O0. > But with a -O2 optimized production build, Emacs keeps up both when I > lean on C-v and when I turn the mouse wheel constantly. Same here. > Anyway, you don't need to work too hard to get me started on how slow > CC Mode is, especially when re-indentation is involved in addition to > font-lock. Which is why I think we should move away of regexp-based > and SMIE-based engines towards fast parsers written in C. As long as we are not there (and IMO even after that) Emacs should be able to do its SMIE parsing in a practical way: Restrict backward and forward parsing to the smallest reasonable code fragment around point. And reasonable would mean the smallest enclosing fragment delimited by two parens in column zero it can find in either direction (which can be still quite large when viewing functions like redisplay_internal). martin