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.bugs Subject: bug#62368: 29.0.60; Evaluating predicates before creating captured nodes in treesit-query-capture Date: Wed, 22 Mar 2023 20:16:14 -0700 Message-ID: References: <09A7EAB7-332E-4123-A6DB-8921FBD325C4@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) 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="36532"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62368@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 23 04:17:21 2023 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 1pfBS5-0009HV-4V for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Mar 2023 04:17:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfBRq-00024J-0Q; Wed, 22 Mar 2023 23:17:06 -0400 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 1pfBRm-000244-EJ for bug-gnu-emacs@gnu.org; Wed, 22 Mar 2023 23:17:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pfBRm-0001UU-3b for bug-gnu-emacs@gnu.org; Wed, 22 Mar 2023 23:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pfBRl-00060M-Qg for bug-gnu-emacs@gnu.org; Wed, 22 Mar 2023 23:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Yuan Fu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Mar 2023 03:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62368 X-GNU-PR-Package: emacs Original-Received: via spool by 62368-submit@debbugs.gnu.org id=B62368.167954139523029 (code B ref 62368); Thu, 23 Mar 2023 03:17:01 +0000 Original-Received: (at 62368) by debbugs.gnu.org; 23 Mar 2023 03:16:35 +0000 Original-Received: from localhost ([127.0.0.1]:37012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfBRK-0005zN-RU for submit@debbugs.gnu.org; Wed, 22 Mar 2023 23:16:35 -0400 Original-Received: from mail-pj1-f47.google.com ([209.85.216.47]:46913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfBRI-0005yx-2i for 62368@debbugs.gnu.org; Wed, 22 Mar 2023 23:16:33 -0400 Original-Received: by mail-pj1-f47.google.com with SMTP id f6-20020a17090ac28600b0023b9bf9eb63so637593pjt.5 for <62368@debbugs.gnu.org>; Wed, 22 Mar 2023 20:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679541386; 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=LLNRFoM/WdIe6yovVe6mu7SnKSeLGPQ1mvFYOibg8Lk=; b=GPCKtC3+CTFh9Zu7Mqr1F12MsDrIVa7AVcczArCnSQqmLNsTgSKrMk6mKiN9Z2fDvy rU4GRSXuQ/Ey3RXCGiH3w3VCLZ4TwOZ3kzFidzkqwGehc/zWxN3+tFtWcqj3/0rfE0Az Gg1EdJDAprxxsChmv9/nWJBypvU2un7QrojMjYC0q5wJBTLnhUq8bBeGh4NKf7SchfB8 d7A90hJSTlMMIaRqiCgmPdw9uFArUC/ruoCCN6L/QEIH4I8JjVfnI0Ro/tUOaRo36aUw WqD/3Vn+yWlMf0LLW9/twLxzxqwNiD08Z5QmRifNzmVV/S14MDK6fbcJfbgu5Cw+zHak bekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679541386; 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=LLNRFoM/WdIe6yovVe6mu7SnKSeLGPQ1mvFYOibg8Lk=; b=F3Sf6OxyHaond2+iVgUSNZLxEH0uD20YdDa6lJb9jBG+pUZ3p4bE9c8ewpHxrJ+n+S G+Q9ehB+anpfErb6sfSkfacJvylLbTvjg+P4gPTDLUFGWYAfZt6VY3Gpp4QcHKbGk5b2 XBBrSVFfL8ZEzpjQrWI3qibmr66PVvfKQzXLtYce+MbN/eNz7noZgu3fIRU23GSJ/EZv s2eow6obs0Fw5HGW4txZpq242TF7hFremCulpEYaBK3Y0BevTFXBL3z5XMTFmM7WPQy3 3j7THolzolucjSsgCVMjU9ye4wRiJ+hokhUC0E8KgYaIgWdnthSh+FbVoLid6oPHF59t UblA== X-Gm-Message-State: AO0yUKV3YkiiOVaDEONYPiGQai6jQKu5ByOFY08cFiUdqtC3fGoUHUU0 OsvyBAI6Yb5iO2BOBpXn0mA= X-Google-Smtp-Source: AK7set9N8qNsVEX9tGDEe/viWIxD0Bt7jrF2Ap6/RwwsyHeDWLlSsEdI2nD2E30OjNvwKgfn4D38uA== X-Received: by 2002:a17:903:300c:b0:1a0:4b23:84a with SMTP id o12-20020a170903300c00b001a04b23084amr3579718pla.46.1679541386278; Wed, 22 Mar 2023 20:16:26 -0700 (PDT) Original-Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id p14-20020a170902a40e00b00198e7d97171sm11226529plq.128.2023.03.22.20.16.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2023 20:16:25 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3731.400.51.1.1) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258426 Archived-At: > On Mar 22, 2023, at 5:42 PM, Dmitry Gutov wrote: >=20 > Hi Yuan! >=20 > On 22/03/2023 06:49, Yuan Fu wrote: >> X-Debbugs-CC:dgutov@yandex.ru >> Dmitry, when you have time, could you try your benchmark in bug#60953 >> with this patch? I made predicates evaluate before we create any = nodes, >> so #equal and #match should be more efficient now, when there are a = lot >> of rejections. In the same time #pred is made slightly worst since = they >> now create a lisp node and discard it. (But this can be fixed with a >> little more complexity.) >=20 > Thank you, I was curious what would the improvement be if we could = delay allocation of node structures until :match is checked. >=20 > But for my benchmark the difference is on the order of 4-5%. It seems = we are scraping the barrel in terms of improving allocations/reducing GC = because according to 'benchmark-run', where the whole run of a 100 = iterations of the scenario takes ~1.1s, the time spent in GC is 0.150s. = And the improved version takes like 1.04s, with 0.1s in GC. >=20 > So if you ask me, I think I'd prefer to hold off on applying this = patch until we either find scenarios where the improvement is more = significant, or we find and eliminate some other bigger bottleneck = first, after which these 5% grow to become 10-20% or more, of remaining = runtime. The current approach is pretty Lisp-y, so I kind of like it. >=20 > And there's the issue of #pred, of course, which which could swing the = difference in the other direction (I didn't test any code which uses = it). >=20 > We could also try a smaller change: where the initial list of conses = for result is build with capture_id's in car's, and then substituted = with capture_name if the predicates all match. Then tthe treesit_node = pseudovectors would still be created eagerly, though. Thank you very much! Yeah, it doesn=E2=80=99t seem to worth it. I guess = we can keep this in our back sleeve for now ;-) I think using symbols is fine for now, since I don=E2=80=99t think it = would make much difference. Yuan=