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

[Yuan Fu]

> 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