From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: treesitter local parser: huge slowdown and memory usage in a long file Date: Tue, 13 Feb 2024 00:15:49 -0800 Message-ID: <2F0B4B85-5EAB-4285-BB6B-6CAF24EB96C3@gmail.com> References: <5991618.MhkbZ0Pkbq@fedora> <93F7DE13-0EC7-4A17-89B1-E07C99C6347B@gmail.com> <864jedsrjt.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Vincenzo Pupillo , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 13 09:16:57 2024 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 1rZnyK-0003JV-Pb for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Feb 2024 09:16:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZnxW-0007kg-Pf; Tue, 13 Feb 2024 03:16:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZnxV-0007kJ-2M for emacs-devel@gnu.org; Tue, 13 Feb 2024 03:16:05 -0500 Original-Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZnxT-0001cK-6E; Tue, 13 Feb 2024 03:16:04 -0500 Original-Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-2909a632e40so2372517a91.0; Tue, 13 Feb 2024 00:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707812161; x=1708416961; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XOddV3ahfSG4XhcZJiYHqW7HWU2a5DI3Ns67U5I2NpA=; b=TxivVK+ZR4xpZ29PO7az7z73VYMbEeSEBpa8D6A2QUINGvOgRNZEfs6m9cvRmKo2Bx y00GDcCLYWdYaqr0citRtLwERtyOVEnS86PHmOVphuyH8gz44SeyUMavZe1CNpFRKizr WMmYNR60jnpvLnen2DVQj6eFxZYRFaNYeiiVGKu4rFjsxbAorppYU4lVXP1hOI9aIFkw 4SqLWKhtuBQkI7v+ev59lG4e4maIyy7wKER8NQsxm3jAso6NN5Gm1/lg0Qj9uazCmu2V pSaxxAIZ9BVuQ8BHNglVNhwd1QKNkb2O4b82Niw2PgpiLKAPz65sQfuMV2lQy6DBRnQ7 0A+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707812161; x=1708416961; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XOddV3ahfSG4XhcZJiYHqW7HWU2a5DI3Ns67U5I2NpA=; b=dp1Yb+tUc5U1VVt1H7EyI1aDQTgtkXGcku+s4RC67W2Ya9jQxx1iunbKMmUSIF23x6 8oRY1VwKr+nk53mY2GdUEecOTypfq6cNyrHuK2VyKmFPDvV/nTKA6cMJhAxT8XIfjhSn B8iO044e95QGxgN7/L3SEg75qlOFKiy4DvCasWpoFYwfyfu01rziscrJ/PgER0MK076m 9dvgST/hcG2dEyhB41gF+Tojm2xpWu54abPqqWI6oHay+IgIbtOXN8niLt4tHJ+VvjYh T4Da+d+U9qigrm+SqbZLC6oUNl18ze7VcoypozJz3lpvvXvWijsbYRYf2R4MnoDK4oZP VHFA== X-Gm-Message-State: AOJu0YxhZNE2kk4+BAWC8K6TMk2BTxv6IkIdLSI9cXhgUW8X5v9Hwyma jk/E3PsBuXeMWO9OLy/i0Na352Gjgg37thEUyDKJbIiGQ1mC42+ZcXQy9Q3Z X-Google-Smtp-Source: AGHT+IEdAIIQ+mBeBw5VlGH5fVJ9/5c8QMKl6LNoAQivBU63UkCQxvvB59AsMJRMXfCxoPfARZSLIA== X-Received: by 2002:a17:90a:c58b:b0:297:285e:9a93 with SMTP id l11-20020a17090ac58b00b00297285e9a93mr3603794pjt.46.1707812160976; Tue, 13 Feb 2024 00:16:00 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXFggtvW/GeCVMxohEqcTzGbd0A8K4VRuvRAmQ1mQL1X1guY1XTaYgW4Y4ZPvg4S/a0Ji0wIgn0EVP5R9PwGrvuqcp9 Original-Received: from smtpclient.apple (172-117-161-177.res.spectrum.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id su14-20020a17090b534e00b002960e3745d9sm1894937pjb.13.2024.02.13.00.16.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2024 00:16:00 -0800 (PST) In-Reply-To: <864jedsrjt.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.700.6) Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=casouri@gmail.com; helo=mail-pj1-x1036.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=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=ham 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316167 Archived-At: > On Feb 12, 2024, at 6:09 AM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Sun, 11 Feb 2024 20:16:11 -0800 >> Cc: "Ergus via Emacs development discussions." , >> Eli Zaretskii >>=20 >> Thanks, the culprit is the call to treesit-update-ranges in = treesit--pre-redisplay, where we don=E2=80=99t pass it any specific = range, so it updates the range for the whole buffer. Eli, is there any = way to get a rough estimate the range that redisplay is refreshing? Do = you think something like this would work? >>=20 >> (treesit-update-ranges >> (max (point-min) (- (window-start) 1000)) ; BEG >> (min (point-max) (+ (or (window-end) (+ (window-start) 4000)) = 1000))) ; END >>=20 >> I guess the window-start would be outdated in = pre-redisplay-function... >=20 > The problem is that window-start is not guaranteed to be up-to-date > when pre-redisplay-function is called: the window-start is updated by > redisplay, and pre-redisplay-function is called before the update. > Moreover, pre-redisplay-function could be called either once or twice > in a redisplay cycle, and window-start is up-to-date only for the > second call. >=20 > The window-end point is basically never up-to-date during redisplay, > only at its very end. >=20 > So my suggestion would be to define the range from position of point, > using the window dimensions; see get_narrowed_width for ideas. This > could lose if the buffer has a lot of invisible text, so I suggest to > check for invisible properties, and if they are present in the buffer, > punt and use the whole accessible portion of the buffer (I don't > expect PHP buffers, or any buffers in programming-language modes, to > have invisible text). Ah, clever :-) Programming language buffers could have invisible text = when the user uses hideshow, or folded some section of code using = outline-minor-mode :-( But as I said in the reply to Dmitry, we might need some better design = for updating parser ranges than the current one. I=E2=80=99ll just fix = V=E2=80=99s problem for now by updating the range around point, and = ignore invisible text for now. Yuan=