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.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Tue, 9 Aug 2022 21:52:18 +0300 Message-ID: <8d08c724-3b35-8dd0-bef4-e90de7c7fd65@yandex.ru> References: <6ae35c9306ade07b4c45@heytings.org> <83fsi7wjqe.fsf@gnu.org> <838rnzvup5.fsf@gnu.org> <3036db04-df93-2dff-0364-1e59f95772bc@yandex.ru> <83fsi5veln.fsf@gnu.org> <3733e7b0-a5f3-68bd-fbe0-0da535c37381@yandex.ru> <834jylv1k7.fsf@gnu.org> <82047505-a601-dcb8-ba76-7c0c62cf4ae5@yandex.ru> <83pmh9tkj2.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="blaine.gmane.org:116.202.254.214"; logging-data="18749"; 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: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 09 20:59:38 2022 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 1oLUS1-0004gQ-4A for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 20:59:37 +0200 Original-Received: from localhost ([::1]:33286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLUS0-0001Gz-06 for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Aug 2022 14:59:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLULK-0001fQ-Ov for emacs-devel@gnu.org; Tue, 09 Aug 2022 14:52:45 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:47024) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLULI-00027W-KZ; Tue, 09 Aug 2022 14:52:42 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id l4so15260620wrm.13; Tue, 09 Aug 2022 11:52:22 -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=j3S/77PXZi9bk+a5nc7bWL+/zVPya6wZidhMIM8Jqbo=; b=Clnln7u8WBlvTK41OWAI0pWuqhgovXUxVNDwzEpi5/m/ZJPtWO0SfX6ho5qVRJutYB u9YcNI45BERSwh34js2stxbbyXDy4kOhlXGXyTEtJmRl/r1+r+Rt0s0QqQC+YVIOH+b8 VpirvRuMoXKOh8vRUd1jUk18/51DsQN7vkMPzdeQCF1JEAjKtm6DoYUIxXn2VXOs9lvu WJRhVzrFYbJYGTHbn/czS7gIkzwbmkr3oVBO/Cq4OjyACOXrCvhpKCw/JkExD1IjgSo+ k6hGM1RwDmUoR5m3mc6O9KFaDEg+7WYGIVGmyfCLRRu9JPxFwEu9FdnuOWU192h+KSfI PqiQ== 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=j3S/77PXZi9bk+a5nc7bWL+/zVPya6wZidhMIM8Jqbo=; b=JtKQ1zi5Rxu5a0bUUW4szJD1AYFxb2xnUdETi8htrGvqgVQr9+ihQWCgWIysEOiKUf DBWDBJ7BRBPNF9Lis4aNrcaaeZxlPd1tjfhfScarCGLZFqtrOjg5PN/l6ThZfZmIw0s/ 2ZkdQoWdLT6MF5LvxO68GIUknc+ArQzbOFRY1UvSDgHI1/IsJX5ZPSmPObklMvplk6ov fPJsMmPHQYX/VyaEMckGSC3424IEHjlZgeCTVaWWW6iKr9TdD55Rz4ZAq+hozVBpYqN8 PgQRWst9L6zu+d9lAoc1z1UI27UBqYnncxiofDhkG7TxcICTrujs6V7pQDk1wapVvYYr FGsA== X-Gm-Message-State: ACgBeo118ngk6B1AtD7NVdf2VeaPvZITVHxETlvf4QNiMK2F16QNVxMB /WVj6uwegx3o9wv16f1eLWQ5c03rri0= X-Google-Smtp-Source: AA6agR4Q29nSAhZFgQ8AoRA3R1wImlTgDSQZKbk0NOIkTiZ2cWCrTZH9FF5S94ByTSfIGRQBVkKBXA== X-Received: by 2002:adf:a1d2:0:b0:21e:bc22:f550 with SMTP id v18-20020adfa1d2000000b0021ebc22f550mr15607186wrv.399.1660071141000; Tue, 09 Aug 2022 11:52:21 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n4-20020a7bc5c4000000b003a3253b705dsm16946485wmk.35.2022.08.09.11.52.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 11:52:20 -0700 (PDT) Content-Language: en-US In-Reply-To: <83pmh9tkj2.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293328 Archived-At: On 09.08.2022 20:05, Eli Zaretskii wrote: >> Date: Tue, 9 Aug 2022 19:52:46 +0300 >> Cc: monnier@iro.umontreal.ca, acm@muc.de, gregory@heytings.org, >> emacs-devel@gnu.org >> From: Dmitry Gutov >> >>> Then I don't really understand what is it that you are arguing about. >>> >>> My proposal to Stefan was to make syntax-ppss and friends less of a >>> burden _instead_ of the currently implemented "arbitrary restrictions" >>> that he doesn't like. You seemed to have contradicted my proposal by >>> saying that the file is already displayed quickly enough, but that >>> only happens _with_ those "arbitrary restrictions". >> >> No, it doesn't. >> >> You might recall the patch I suggested recently that doesn't change >> either of those vars but disables narrowing in handle_fontified_prop. > > Why is that of importance? More importantly, how is that proposal > related to what I was discussing with Stefan? We've been talking about "unconstrained" font-lock and the performance problems it causes or can cause. The patch is the way to actually try it without bringing back unrelated performance problems. >> BTW, you can try js-json-mode in the latest master, I have fixed another >> source of slow font-locking there (coming from js-mode). > > I already did. This trime I got impatient more quickly, and killed > the session only after 5 minutes that it was unable to show me > dictionary.json (after disabling the narrowing). Am I correct to assume that you tried it while setting long-line-threshold to nil? That kind of experiment tells me nothing, as explained before. >> Just remove the expression that starts with 'if >> (current_buffer->long_line_optimizations_p)' from handle_fontified_prop, >> recompile, and visit dictionary.json. > > Sorry, I cannot afford trying half-baked solutions. I asked you to > push a feature branch or an optional feature on master precisely so > that I won't need to hack my development branch. When such a feature > is available, I'll surely test it in a variety of scenarios, It's a tiny patch. I can push it to a branch, but it will still be a tiny patch that just removes 14 lines. I'm also working on a bigger change that will push the narrowing/limiting mechanics down to font-lock, but I'm yet to find the best place to put that logic. And the problem with working on a feature like that is that it will be fixing performance problems I don't really have. And, as such, cannot evaluate different tradeoffs. And neither you nor Gregory want to give me feedback by actually trying that tiny patch. >>>> If you concerned with the speed of font-lock itself (and not with the >>>> speed of syntax-ppss cache maintenance which we've talked about before), >>> >>> I'm concerned with both, because font-lock typically calls syntax-ppss >>> in many modes. >> >> "Stealth" syntax-ppss, to have any visible impact, is likely to have the >> problem I described: lots of work, the results of which are regularly >> discarded. Meaning, lost of wasting CPU energy. > > Well, my many years of using jit-lock-stealth clearly prove otherwise. > By the time I get to revisit the buffers after some break, they are > already fully fontified. Then you are not in the same usage scenario that we described before (lots of jumping around *and* lots of editing). Because said edits invalidate the syntax highlighting, forcing Emacs to do it all over again. >> What might work better instead (and would benefit specifically the >> scenario with a lot of jumping around and editing in different parts of >> a large file) is to try to avoid dumping the whole spss cache when the >> use edits near BOB, and instead record the fact of such edits but later, >> but later try to "revalidate" the cache entries by calling >> parse-partial-sexp on the interval where the edits occurred in the >> meantime, and keep them if the result shows that the edits should have >> no effect on the later values. That's something tree-sitter does, AFAIU, >> but for much complex parse tree. >> >> Anyway, that approach would require some work and subsequent testing, >> and it would improve performance for a particular class of operations. >> It's not a given that the performance issues you see in CC Mode fit that >> profile. > > Well, I hope someone will actually try to make that happen. Definitely. But so far I'm not convinced that your impression of CC Mode's "sluggishness" comes from syntax-ppss at all. Or, at least, most of it. And not from CC Mode's approach to maintaining syntax information eagerly, through buffer change hooks (after-change-functions, etc). >> And I hope that somebody could look into improving that 10x difference >> between yours and mine performance of parse-partial-sexp first, so then >> we could see where the remaining bottlenecks are. > > That too. Yep.