Re: Tree-sitter integration on feature/tree-sitter

[Yuan Fu <casouri@gmail.com>]

> On May 11, 2022, at 10:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Wed, 11 May 2022 13:14:33 -0700
>> Cc: Yoav Marco <yoavm448@gmail.com>,
>> emacs-devel@gnu.org
>> 
>>> |   |                                      | no reuse (now) | reuse |
>>> | 1 | Fontify xdisp.c all at once          |          0.01s | 0.01s |
>>> | 2 | Fontify 60 next lines of xdisp.c ×10 |          0.10s | 0.00s |
>>> | 3 | Fontify 60 next lines till the end   |          6.06s | 0.01s |
>>> 
>>> If so, what is the significance of the last line in practical use
>>> cases?  JIT font-lock never fontifies such large chunks of source
>>> code, it does that in 512-character chunks, which is less than 60
>>> lines in most cases, and definitely not "till the end".
>> 
>> I think that’s just a way to run font-lock enough times without repeatedly fontifying the same region?
> 
> Then I'm not sure the result is very interesting by itself, unless we
> can find a way to use that result for estimating how long will it take
> to perform fontifications in some practical use cases that we care
> about, and compare that to what we have now in those use cases.
> 
>> I redid the benchmark, but without his reuse patch, just to see how much time is spent on creating query objects. So fortifying 40 lines for 463 times takes 6.92s (according to Emacs, 7.30s according to the profiler). That counts to 0.0158s per call to font-lock-region, of which 0.0104s is spent on creating the query object. That seems to tell me if we optimize away the query object creation we can make font-locking very very fast?
> 
> According to your benchmarks, it is already very fast: 16 msec is a
> negligible time interval.  Of course, 40 is a somewhat arbitrary
> number, but to get a less arbitrary one, we should determine it from
> some concrete scenarios, such as the 512-character chunk JIT font-lock
> uses during redisplay, or the number of lines on a typical window
> that's important when one scrolls with C-v/M-v, etc.
> 
>> If we expose "compiled query” we don’t need to cache them either.
> 
> Then the Lisp program will have to do that, which is even worse,
> because the problems I described will now have to be solved by Lisp
> application programmers, each time anew.
> 
>> Benchmark 3: fontify all of xdisp.c, 40 lines at a time.
>> took 88.28, of which 5.00 is GC (4 gc runs), loop count: 905
>> 
>> font-lock: 88.28s -> 0.1997285067873303 / loop
> 
> So we already have an order-of-magnitude speed-up with tree-sitter: we
> go from 200 msec down to 16 msec.  Also, 200 msec is above the
> threshold of human perception of a response delay, whereas 16 msec is
> way below that threshold.  With such significantly faster font-lock, I
> wouldn't bother caching anything, at least not yet, not unless someone
> comes up with a practical use case where the query-compilation part
> really makes a significant practical difference in terms of absolute
> response times.
> 
> Bottom line: I think the 6-msec speedup (from 16 to 10) in the
> scenario that was used in these benchmarks doesn't justify the
> complexities of caching the queries, given the overall excellent
> performance we get with tree-sitter.  Caching is an optimization, and
> in this case it sounds like doing that now would be a premature
> optimization.

Sure, that makes sense, and I save writing code ;-) If we want it later we can easily add that without breaking any API.

Yuan