From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sun, 7 Aug 2022 20:40:53 +0300 Message-ID: References: <83v8rf5894.fsf@gnu.org> <65cb7c73fd4a999cca00@heytings.org> <8c7321f2f3400a5db9be@heytings.org> <8c7321f2f388e5343475@heytings.org> <8c7321f2f36494299e61@heytings.org> <83v8rc2n1h.fsf@gnu.org> <64084296-1953-8ef8-5938-adfb6fb9b43f@yandex.ru> <83r11uzs8n.fsf@gnu.org> <14845631-c2ef-8371-8606-c858092e3192@yandex.ru> <83mtcizov2.fsf@gnu.org> <83h72qzheq.fsf@gnu.org> <25717d84-3411-a93a-3620-e04fe0571aff@yandex.ru> <83edxuzemr.fsf@gnu.org> <83a68hzz0a.fsf@gnu.org> <6ae35c93062c589b2e02@heytings.org> <7b7fbad7-55ac-49b8-840f-7f89a7e8771a@yandex.ru> <6ae35c93064b3588974c@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7235"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: 56682@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 07 19:42:56 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oKkIh-0001eJ-ML for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 19:42:55 +0200 Original-Received: from localhost ([::1]:40698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKkIg-00080p-Av for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 13:42:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57578) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKkHr-00080R-9R for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 13:42:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48512) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKkHq-00036Q-2e for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 13:42:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oKkHp-0002Rm-Sa for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 13:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Aug 2022 17:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.16598940689320 (code B ref 56682); Sun, 07 Aug 2022 17:42:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 7 Aug 2022 17:41:08 +0000 Original-Received: from localhost ([127.0.0.1]:38254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKkGy-0002QF-2i for submit@debbugs.gnu.org; Sun, 07 Aug 2022 13:41:08 -0400 Original-Received: from mail-wm1-f52.google.com ([209.85.128.52]:50770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKkGr-0002PZ-OA for 56682@debbugs.gnu.org; Sun, 07 Aug 2022 13:41:06 -0400 Original-Received: by mail-wm1-f52.google.com with SMTP id v5so3737405wmj.0 for <56682@debbugs.gnu.org>; Sun, 07 Aug 2022 10:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=wAdf9F+r5GC7+K7mRCWny/cMMHfTJUIGX7wqoKHDNag=; b=pPDEKiYENLcEzPtWFKl+yZtfDGeB3FGCWWDSvSQY3lkucKdCFcyKc3YovE7fC+Y6jP QRIAz2lD2brZHPaXUVCUbdjaFeGVfsxNuiS+R7jyDSb06ChkkNdN6+rVlrp5oQ3hEQre ITg3PV6c4hFoJ/kQ8MP2ijOp4l2Bd2Kq2Gc+0bjg6Or7QtAh+jf19MT726lDvAIKzYVX QA3Kd+UXhfUumQIf00Ues+ORZCvY3MJlXCbCyh99S11sa/+W1+vK//ZPOa8xyifFGmZY pnHYoWMxlV30Ad41TkvFC4RgUqgiwIAkSufFw1cWwcusEZzlVamzzWY6Ye+sgvWhHSnp wd/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=wAdf9F+r5GC7+K7mRCWny/cMMHfTJUIGX7wqoKHDNag=; b=gKiEa2APOkeUqno2AcT7+tj7PgCb0RBcBkJlbsmxn6Unsh2LtWfnlGHeiPkKHnuz2m ThjBmP4gWQHYsh/VF0S/LWJF5SfTaWH0CLxy5SqsgH/odvQAC2t9tWjQldUg0ZaJdI+o 9oSWG6m8Cv9OddHSZXaPVhVF+iY1KTTB9P+pR2J0EWkgfXFG59vNqCtse5J9e8TiABn+ 3KjMVqr9TogwNwvcPhG8MNTiZKjOEoqS5ON70HCv3GQY8A3oDnjIvxpAEdPgHnUMb1bL +2RKxd8UUQLwS+XFPwN7HLUE0HE5oSPPJeUbDnT7hQvYHtRIZduMd9dtRXmpXmK/MevO wrtQ== X-Gm-Message-State: ACgBeo1fH/eBqTnkfUfCINdYe9hiTmZ5Pg57zH+iT96etfUS3v14wwRp xG4dLp0eyvjOhZECfqdwiyM= X-Google-Smtp-Source: AA6agR5In+ggL1vi4ZFlhnkVhxGoy27l3PonYCXVUnvTx/POz/dgpVt7hPLbMu3InJHrbCaxFd11jg== X-Received: by 2002:a1c:7508:0:b0:3a5:923:3994 with SMTP id o8-20020a1c7508000000b003a509233994mr10114294wmc.173.1659894055720; Sun, 07 Aug 2022 10:40:55 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f13-20020a05600c4e8d00b003a319b67f64sm40288039wmq.0.2022.08.07.10.40.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Aug 2022 10:40:55 -0700 (PDT) Content-Language: en-US In-Reply-To: <6ae35c93064b3588974c@heytings.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239082 Archived-At: On 07.08.2022 15:46, Gregory Heytings wrote: > >>> They aren't, no.  Of course it all depends on where you are in the >>> file, on your CPU, and so forth.  For me (with locked narrowing >>> disabled, in dictionary.json, with emacs -Q) M-> takes about 3 seconds. >> >> And it's about 1.5s here. >> > > So you're the lucky owner of a fast computer.  And using an optimized > build.  Not everyone is in that fortunate situation. If your computer is 2x slower, that should mean it can handle twice smaller files with approximately the same speed. So, qualitatively, you should be in the same boat. >> >> Once. >> > > No, not once.  It happens every time you modify the buffer and move far > enough in that buffer. Yes. That's the price of re-parsing the buffer the way that we know how (with parse-partial-sexp). The only feasible comparable alternative I know of is tree-sitter which has a more advanced parser that knows how to amortize certain operations modifications faster than O(N). So, with the tree-sitter integration that's hopefully coming, we should be able to get a speed improvement in handling of huge files, too. If it doesn't blow up the memory requirements, that is. >>> Likewise, if I do for example C-s aan, and then repeat C-s, whenever >>> the next match is far enough in the buffer I see a delay of about 2 >>> seconds. >> >> Sounds like a performance problem inside isearch. I might take a look. >> > > No, isearch is entirely agnostic about font locking. I wonder where it spends those 2 seconds, then. >>> Another test you can do is to lean on C-v after opening the buffer, >>> you'll see that Emacs becomes very sluggish, sometimes I have to wait >>> more than 5 seconds to avance from one screenfull. >> >> First of all, these aren't the tests Eli asked for or I performed. Why >> don't you compare apples to oranges? >> >> Leaning on C-v isn't a scientific test anyway: it compares the speed >> of two processes internal to Emacs (event handling and rendering), >> rather than something objective. >> > > It's yet another test meant to test Emacs' responsiveness, and it is as > "objective" as possible: does Emacs choke or does it not? It's not a test of font-lock's performance, however. Because it compares that to a process that's internal to Emacs as well (moving across the buffer with C-v). Like, the faster we're able to make the latter command, the faster font-lock has to be to keep up. As an objective test, it's not meaningful. Now, if we measured how many screens one could page through with fontification in 10 seconds, that's something more objective (putting aside one's screen dimensions, of course). But anyway, it's a nice race, but not as essential as quickly fontifying any particular screen. That's what we're measured responsiveness with in this discussion so far.