GNU bug report logs -
#62368
29.0.60; Evaluating predicates before creating captured nodes in treesit-query-capture
Previous Next
Reported by: Yuan Fu <casouri <at> gmail.com>
Date: Wed, 22 Mar 2023 04:50:01 UTC
Severity: normal
Found in version 29.0.60
Done: Yuan Fu <casouri <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 11 Sep 2023 17:37:49 -0700
with message-id <AAD7971E-339B-4C5F-9BA5-86F22FA07FF1 <at> gmail.com>
and subject line Re: bug#62368: 29.0.60; Evaluating predicates before creating captured nodes in treesit-query-capture
has caused the debbugs.gnu.org bug report #62368,
regarding 29.0.60; Evaluating predicates before creating captured nodes in treesit-query-capture
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
62368: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62368
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
X-Debbugs-CC: dgutov <at> 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.)
Yuan
[pred-first.patch (application/octet-stream, attachment)]
[Message part 5 (message/rfc822, inline)]
> On Sep 11, 2023, at 5:05 PM, Stefan Kangas <stefankangas <at> gmail.com> wrote:
>
> Yuan Fu <casouri <at> gmail.com> writes:
>
>>> On Mar 22, 2023, at 5:42 PM, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>>>
>>> Hi Yuan!
>>>
>>> On 22/03/2023 06:49, Yuan Fu wrote:
>>>> X-Debbugs-CC:dgutov <at> 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.)
>>>
>>> Thank you, I was curious what would the improvement be if we could
>>> delay allocation of node structures until :match is checked.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> 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’t 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’t think it would
>> make much difference.
>
> So should this bug be closed, then?
We can close this for now. Thanks Stefan.
Yuan
This bug report was last modified 1 year and 249 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.