From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Tue, 16 Aug 2022 18:49:09 +0800 Message-ID: <87edxg31lm.fsf@localhost> References: <1144021660321893@iva5-64778ce1ba26.qloud-c.yandex.net> <12348081660379417@sas2-a098efd00d24.qloud-c.yandex.net> <66bbbb95983414e79637@heytings.org> <83wnbckp0q.fsf@gnu.org> <8e884ebe-2d2e-d599-15c3-a5cfe5e6b295@yandex.ru> <83o7wnl7ok.fsf@gnu.org> <036414cc-c711-efaf-ed5b-f8ccfaca0604@yandex.ru> <5900f20836753183a6ac@heytings.org> <5c22e38a-5dcd-860e-28a0-b4a5ede6a21b@yandex.ru> <877d3awb92.fsf@localhost> <87pmh2z277.fsf@localhost> <87mtc6yzfv.fsf@localhost> <3a1232a17bf48a4a693e@heytings.org> <87lerp4tk1.fsf@localhost> <325f95fd2bdd2289114b@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="693"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier , Dmitry Gutov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 12:49:11 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 1oNu8E-000AU0-V3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 12:49:11 +0200 Original-Received: from localhost ([::1]:34722 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNu8E-0000qW-3H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 06:49:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNu86-0000mx-Vk for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 06:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55308) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNu86-0002uN-MU for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 06:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNu86-0003Pr-IE for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 06:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Aug 2022 10:49: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.166064689313060 (code B ref 56682); Tue, 16 Aug 2022 10:49:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 16 Aug 2022 10:48:13 +0000 Original-Received: from localhost ([127.0.0.1]:45057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNu7J-0003OX-9J for submit@debbugs.gnu.org; Tue, 16 Aug 2022 06:48:13 -0400 Original-Received: from mail-pf1-f171.google.com ([209.85.210.171]:33348) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNu7H-0003Nt-Ia for 56682@debbugs.gnu.org; Tue, 16 Aug 2022 06:48:12 -0400 Original-Received: by mail-pf1-f171.google.com with SMTP id k14so9032282pfh.0 for <56682@debbugs.gnu.org>; Tue, 16 Aug 2022 03:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=GsucCvLOJu5j5Lh4+yceJNAAxrMUbjaeDwZBgzjAa28=; b=cmmfe5X+pRkZ97VScnwLilHfzdInOAcmnCRiDEOusIwxVXaif42Jx4RnTUy/GP+f8L LUzCrKZ4P1ukwwCVTOX5nxXdWtTRuH4WWSIRICGq17L6Q7HFT7K8qjDidf+qQzsObM73 d9z0FABri9iciRSrvjk8zTVqCaWBaqn1+2zKhRLFIkUsZ6hKDEh56usYKykXn9W93T4Y IVa/rQx13/PQekGXhzLHUYleCmS4hwaTzDjNyV9Ra65EAGFawlsM2JUn+vR4eLRkwxHH 89fFOtWX0Tj6C6P8zQdAgsZfivIuvnaSpw5Ha3XTvOuyaihrnLUXFkPu3ZNvDMksunnk Vk7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=GsucCvLOJu5j5Lh4+yceJNAAxrMUbjaeDwZBgzjAa28=; b=W0qVOdfLm+9NA57ZqLim2YXpXawjKT7IJoSOLb+z2jGZ+DasYdSnlUoz6B1cXcsOgg SfcxknsPL7m+BgTRXGNjwfhmWQYa11flCBLumXJjI1Aa0CkNbacBtVtSH+GIfUPPXdsy XZ8GDKjWOaTznPlsbBt9a5MoABK2PnwzHIDcTkA9YpWLuv2Qu8+G23BN0ihBAEe3fbnA nTpCMsKA40j37YySZpQNvjJtAf4S/nLjdVOFFQmuKXxWkVOTcbFDe/ztpmZNdNY9Wo39 aOV4EJLpleHT0jisKrzG9U2sPWYjKf4I7aSEuyLhFrhwBSgQaH2f3zhQYEEq8VaMMypT oQBg== X-Gm-Message-State: ACgBeo1+SYftMU5jxGrKe22vXBkeXQFtDAMmfxMQL8P8N5z0b+OcpOiw bW94SaFDJSebRxSEg4iidos= X-Google-Smtp-Source: AA6agR7qGPssjaglFHfCZXV3m5OFJT4IHESyX7RsMm440Kl1aH95WRYekBvg0BMMVzVEFhTfo+kpSg== X-Received: by 2002:a05:6a00:1d9e:b0:52d:aa13:67fc with SMTP id z30-20020a056a001d9e00b0052daa1367fcmr20299633pfw.73.1660646885807; Tue, 16 Aug 2022 03:48:05 -0700 (PDT) Original-Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id z6-20020a170903018600b0016d2db82962sm8882660plg.16.2022.08.16.03.48.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Aug 2022 03:48:05 -0700 (PDT) In-Reply-To: <325f95fd2bdd2289114b@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:239891 Archived-At: Gregory Heytings writes: >> Cache existence is not guaranteed. >> > > Can that cache not be created unconditionally when the Org file is opened? Without cache, the parser will have to process everything on every request to determine object at point. >> When cache does not exist, Org must widen. If not, the cache will be >> valid only for the current narrowing. >> >> When cache do exist, Org may not need to widen. But that also mean that >> widening has happened in the past when the cache was generated. >> >> At the end, Org does need to be able to widen safely. At least in some >> cases. >> > > That will always be possible. What should better be avoided is to use > widen (and to scan the whole buffer) in performance-critical places, such > as fontification-functions. We tried to. In fact, public Org repository does use regexp search and tries to scan as little as possible inside fontification-function. However, that approach proved incorrect in a number of occasions. We have a stable stream of bug reports related to incorrect fontification. Some were fixed by creating more intricate heuristics, but we reached the point when using the parser can be actually faster compared to the fragile heuristic tower in our fontification code. Our parser, in fact, does not really scan the whole buffer from the very beginning to determine object at point. It only parses the minimal possible portion that is sufficient to determine syntax object at the requested position. This scan is very fast and becomes even faster with caching. But it does need to look at the whole buffer because Org syntax is context-dependent. Previous objects outside narrowing can alter the syntax inside. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92