Re: Semantic font-lock for Java

[David Engster]

>> From: David Engster <address@hidden>
>> Cc: Anand Tamariya <address@hidden>,  address@hidden
>> Date: Fri, 24 Jan 2020 18:00:02 +0100
>> 
>> > So we are talking about a 17% slow-down?  Not bad.
>> 
>> Yes, but to be fair, this does not include the initial parsing by
>> Semantic/Wisent/Bovine. This is usually done for the whole buffer when
>> Emacs is idle, and not during scrolling.
>
> So what happens when the file is visited and its first window-full is
> displayed?

I can't speak for how Anand has configured his Emacs, but the default is
(was?)  that the file is displayed first and after a short idle time (1
second?)  Semantic will start parsing the current buffer. If you use
Semantic's "decoration mode", overlays will be put on the parsed
structures. So my guess is the scroll benchmark is simply 17% slower
because there are more overlays in the buffer, not because of actual
parsing.

The parsing itself is pretty slow, unsurprsingly, since it is all in
ELisp. Eric has invested a ton of time to make it bearable, mostly
through aggressive caching and by making the parser as "lazy" as
possible (only parse what is currently needed and do the rest when Emacs
is idle).

That being said, I of course welcome Anand's work which shows that we
already have a framework to store and query ASTs in Emacs. If we want to
incorporate something like Treesitter, one should at least take a look
at it.

-David