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 14:28:27 +0300 Message-ID: <7b7fbad7-55ac-49b8-840f-7f89a7e8771a@yandex.ru> References: <05388e8d8812bfa3695d@heytings.org> <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> 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="8970"; 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 13:29:18 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 1oKeT8-0002E7-Fu for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 13:29:18 +0200 Original-Received: from localhost ([::1]:46846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKeT7-0006Q6-6P for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 07:29:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKeSs-0006OQ-U0 for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 07:29:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46319) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKeSs-0004bD-Lg for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 07:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oKeSs-0000cO-GG for bug-gnu-emacs@gnu.org; Sun, 07 Aug 2022 07:29:02 -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 11:29:02 +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.16598717182346 (code B ref 56682); Sun, 07 Aug 2022 11:29:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 7 Aug 2022 11:28:38 +0000 Original-Received: from localhost ([127.0.0.1]:36068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKeSU-0000bl-DX for submit@debbugs.gnu.org; Sun, 07 Aug 2022 07:28:38 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:36539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKeSR-0000bX-S1 for 56682@debbugs.gnu.org; Sun, 07 Aug 2022 07:28:36 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id j7so8018449wrh.3 for <56682@debbugs.gnu.org>; Sun, 07 Aug 2022 04:28:35 -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=KI+yBGbdqRH2emrPp5na4hqQrn1eY5HqMJ3CZbr3PCw=; b=Z/TxyPae9nHS3Zr5acEhzaWjuYn4oIcJUMbKE9lLtS/aIG4IQPuTrj9ShKDa16+diQ YtL1FoKqTUOtmX0XyRfWxVeTdTxEQdSVVEIr/EqxGgBivNHLvQoGmfR7q1heyBJLc2Mv +ByjbJiZJ0tpeOR76MF1dXrFf1X8tYroYj+6zQtfdBS27Jmo8jy6LKpGPpUt++joih6R WkJQtlBUw8W6mHlhlCkPo207SF0l4MzDTJ9ypXeOSw7x6I0+YcvtClucJx9sX5YIbEkg w7v6lvGPWbGLQ+GshhS4YANw1eOfIYCfor8YJg9UJi0J1iUrXqpnuVThDwKp9BIMo/kh kgRQ== 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=KI+yBGbdqRH2emrPp5na4hqQrn1eY5HqMJ3CZbr3PCw=; b=nRnPEbqoCSd1CjLIjVf+oJtvIXyQn1y+jtS4ZvIRhoW5JNxNIQL2TP6v66vslm2Uj/ AUsC0FlN3xFmo5NK4I6ekRitwW7VJ3jkBxXYtn4dNRKjSLoJDp2Hnvm32gsZyfa/SCwu VitgbtbUR4ZcjK7QTHVFblQu97dALekK8TqPaDOWSR4nss+pj57jX48d24jgtji9wUyD HVAJmNxbP84nJOFKz5mD13RkE5ipDXbHMa+YdO6JiO79grbPw6ilc0iHgmCmXBBmFlQA kCC9PsFQAlPrHpTDO2nl+S2PVnH2JyKQ09JUOP+T5zI2SBlZtyUVGM8U/shVDOYcG5vC qofA== X-Gm-Message-State: ACgBeo2Y39tKQB6XZZhalH4hDybXK2l1RiDMWS6sAX/hRw7QUxxn7FiR tdbXLdFF90r0wgjfIiCaLck= X-Google-Smtp-Source: AA6agR4Zs6JEFLxfs/42HfPRJ5nLav2ZN1W443bpa6HlTh7EZ1avsG4i1Z2JnVH0//pHFiPSn93CSA== X-Received: by 2002:adf:fb03:0:b0:21d:70cb:d6b5 with SMTP id c3-20020adffb03000000b0021d70cbd6b5mr8552203wrr.548.1659871709915; Sun, 07 Aug 2022 04:28:29 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n66-20020a1ca445000000b003a513ee7830sm12296943wme.27.2022.08.07.04.28.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Aug 2022 04:28:29 -0700 (PDT) Content-Language: en-US In-Reply-To: <6ae35c93062c589b2e02@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:239041 Archived-At: On 07.08.2022 03:11, Gregory Heytings wrote: > >>>> I'm not seeing any particular sluggishness in these operations when >>>> visiting dictionary.json. >>> >>> Numbers, please.  You have a very fast machine, so what doesn't look >>> sluggish on your system could very well be so on others. >> >> How do you measure these operations including the redisplay lag? >> >> Anyway, all of these look instant. >> > > 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. Once. > 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. It shouldn't force font-lock over a big region, and if syntax-ppss cache is already filled, there is no other obvious place for that delay to come from. > 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. And waiting for X seconds means you wait for however many screens you managed to page through, for all of them to get syntax-highlighted. That is indeed a way to break the "jit" in "jit-lock", but how is that a useful test? Anyway, could you please try the combined patch I posted recently together with dictionary.json? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56682#1084 >> Correct syntax highlighting requires parsing the buffer from the >> beginning. Otherwise we get random results, essentially. >> > > It all depends how you define "correct".  You may remind that I > suggested to introduce some heuristics in the algorithm. Stefan mentioned such possibility as well. > With > appropriate heuristics, you could probably get reasonably good results > even if you only have access to a small portion of the buffer.  For > example, instead of counting the number of '"' characters from BOB to > know for sure if you are in a string, you mark those that are likely at > the beginning of a string and those that are likely at the end of a > string, and you select the most likely possibility among all > combinations to highlight the buffer portion as well as possible. Any such heuristics are possible, but major modes are the best place to make that decision. And until the major mode has installed something like this, syntax-ppss should default to the "correct" behavior. Which means operating outside of narrowing.