CC Mode -> Tree sitter challenge

CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Hi Eli and others!

So you challenged me to add some more modes that are supported in CC
Mode, but not using CC Mode.  I finally got some free hours, so here's
my first follow-up to your "show me the code".

In this repo[0] you will find support for the following modes:

- javascript  (this is already in tree-sitter branch - but adding
  without cc mode here)
- c
- c++
- java
- css
- JSON
- TypeScript (left out, as it is in tree-sitter branch already)

So - some notes:

1. This is still very early, but I wanted to put it out there so that
others more knowledgeable than me could chime in on some of the
languages. C++ in particular is a language I don't code in, and is
notoriously complex.

2. I've focused mostly on indentation and font locking.  Indentation is
using xdisp code style and the gnu style in general.

3. There's some support for navigation

4. I'll make Imenu, which-func and other goodies later.  I want it to be
usable first.

5. Most other CC mode features such as electric-foo and whitespace
cleanup should be possible to do with constructs outside of cc mode.

When scrolling through xdisp with this variant of C support it is
noticeably faster on my system.  However, I'd like some guidance on how
to provide some benchmarks to prove my guess.  Loading said file and
immediately going to EOB is instant, but in CC Mode takes a little less
than a second.

@Stefan, you mentioned that filling could be extracted from cc
mode. Could you point me either to what/where to look for/at, so that I
can make such an attempt?

Please don't dismiss this with arguments such as "it's a fruit salad",
"there's no indentation styles" and other arguments.  These are things
that can be adjusted as we move forward.  I have a plan for indentation
styles, but haven't made my initial suggestion there.

If anyone on this list could try some of these I would be eternally
grateful, please add suggestions and/or bug reports either here on this
list or at the issue tracker[1].  I'll keep on pushing commits unless
some of you say this is a non-starter.

-- 
Theo

[0]: https://git.sr.ht/~theo/tree-sitter-modes
[1]: https://todo.sr.ht/~theo/tree-sitter

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Aaaaaaaand here are the links...

[0]: https://git.sr.ht/~theo/tree-sitter-modes
[1]: https://todo.sr.ht/~theo/tree-sitter


-- 
Theo

Re: CC Mode -> Tree sitter challenge

[Stefan Monnier]

> @Stefan, you mentioned that filling could be extracted from cc
> mode.  Could you point me either to what/where to look for/at, so that I
> can make such an attempt?

It's been a long time since I looked at it, but I think it's basically
all in or around `c-fill-paragraph`.


        Stefan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> @Stefan, you mentioned that filling could be extracted from cc
>> mode.  Could you point me either to what/where to look for/at, so that I
>> can make such an attempt?
>
> It's been a long time since I looked at it, but I think it's basically
> all in or around `c-fill-paragraph`.
>

Thanks, I'll start there :-)


-- 
Theo

Re: CC Mode -> Tree sitter challenge

[Yuan Fu]

> On Nov 4, 2022, at 1:34 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> Hi Eli and others!
> 
> So you challenged me to add some more modes that are supported in CC
> Mode, but not using CC Mode.  I finally got some free hours, so here's
> my first follow-up to your "show me the code".
> 
> In this repo[0] you will find support for the following modes:
> 
> - javascript  (this is already in tree-sitter branch - but adding
>  without cc mode here)
> - c
> - c++
> - java
> - css
> - JSON
> - TypeScript (left out, as it is in tree-sitter branch already)

Cool!

> 
> So - some notes:
> 
> 1. This is still very early, but I wanted to put it out there so that
> others more knowledgeable than me could chime in on some of the
> languages. C++ in particular is a language I don't code in, and is
> notoriously complex.
> 
> 2. I've focused mostly on indentation and font locking.  Indentation is
> using xdisp code style and the gnu style in general.
> 
> 3. There's some support for navigation
> 
> 4. I'll make Imenu, which-func and other goodies later.  I want it to be
> usable first.

I learnt this from João: you don’t need to write a dedicated which-func function, it by default uses data from Imenu.

> 
> 5. Most other CC mode features such as electric-foo and whitespace
> cleanup should be possible to do with constructs outside of cc mode.

Didn’t know cc-mode has white-space cleaning, I’ve always used ws-butler. 

> 
> When scrolling through xdisp with this variant of C support it is
> noticeably faster on my system.  However, I'd like some guidance on how
> to provide some benchmarks to prove my guess.  Loading said file and
> immediately going to EOB is instant, but in CC Mode takes a little less
> than a second.

I’ve done benchmarks, and tree-sitter is indeed much faster, you can probably find them in the archive. Speaking of archive, how does you guys find old messages in the archive? The search feature on the official archive webpage is unusable.

> @Stefan, you mentioned that filling could be extracted from cc
> mode. Could you point me either to what/where to look for/at, so that I
> can make such an attempt?

I’ll add that it might be a good idea to take out the whole comment, insert them into a temp buffer, fill it with c-fill-paragraph or whatever, then go back and replace the whole comment in the original buffer. Cc-mode’s filling does a lot of invisible insertion and edits in-place, and IIRC it caused problems with eglot before.

[snip]

Yuan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 5 November 2022 00:10:06 CET, Yuan Fu <casouri@gmail.com> wrote:
>
>
>> On Nov 4, 2022, at 1:34 PM, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>> 
>> Hi Eli and others!
>> 
>> So you challenged me to add some more modes that are supported in CC
>> Mode, but not using CC Mode.  I finally got some free hours, so here's
>> my first follow-up to your "show me the code".
>> 
>> In this repo[0] you will find support for the following modes:
>> 
>> - javascript  (this is already in tree-sitter branch - but adding
>>  without cc mode here)
>> - c
>> - c++
>> - java
>> - css
>> - JSON
>> - TypeScript (left out, as it is in tree-sitter branch already)
>
>Cool!
>
>> 
>> So - some notes:
>> 
>> 1. This is still very early, but I wanted to put it out there so that
>> others more knowledgeable than me could chime in on some of the
>> languages. C++ in particular is a language I don't code in, and is
>> notoriously complex.
>> 
>> 2. I've focused mostly on indentation and font locking.  Indentation is
>> using xdisp code style and the gnu style in general.
>> 
>> 3. There's some support for navigation
>> 
>> 4. I'll make Imenu, which-func and other goodies later.  I want it to be
>> usable first.
>
>I learnt this from João: you don’t need to write a dedicated which-func function, it by default uses data from Imenu.
>

Nice! I'll check it out.
>> 
>> 5. Most other CC mode features such as electric-foo and whitespace
>> cleanup should be possible to do with constructs outside of cc mode.
>
>Didn’t know cc-mode has white-space cleaning, I’ve always used ws-butler. 
>

It has some hungry delete and similar stuff

>> 
>> When scrolling through xdisp with this variant of C support it is
>> noticeably faster on my system.  However, I'd like some guidance on how
>> to provide some benchmarks to prove my guess.  Loading said file and
>> immediately going to EOB is instant, but in CC Mode takes a little less
>> than a second.
>
>I’ve done benchmarks, and tree-sitter is indeed much faster, you can probably find them in the archive. Speaking of archive, how does you guys find old messages in the archive? The search feature on the official archive webpage is unusable.
>

Yeah, i tried too, hehe.

>> @Stefan, you mentioned that filling could be extracted from cc
>> mode. Could you point me either to what/where to look for/at, so that I
>> can make such an attempt?
>
>I’ll add that it might be a good idea to take out the whole comment, insert them into a temp buffer, fill it with c-fill-paragraph or whatever, then go back and replace the whole comment in the original buffer. Cc-mode’s filling does a lot of invisible insertion and edits in-place, and IIRC it caused problems with eglot before.
>

Yeah, i was hoping that tree-sitter could do that, but I only tried briefly. Seems most of the (comment) nodes contain the comment prefix along with the commented text. Would be nice to access the text without comment prefix, but I guess we can code or way out of that.



Btw, Yuan - could you tweak indent-region to that it doesn't insert spaces in empty lines? It creates a lot of whitespace changes now :)

Theo

Re: CC Mode -> Tree sitter challenge

[Yuan Fu]

> On Nov 5, 2022, at 12:56 AM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> 
> On 5 November 2022 00:10:06 CET, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>>> On Nov 4, 2022, at 1:34 PM, Theodor Thornhill <theo@thornhill.no> wrote:
>>> 
>>> 
>>> Hi Eli and others!
>>> 
>>> So you challenged me to add some more modes that are supported in CC
>>> Mode, but not using CC Mode.  I finally got some free hours, so here's
>>> my first follow-up to your "show me the code".
>>> 
>>> In this repo[0] you will find support for the following modes:
>>> 
>>> - javascript  (this is already in tree-sitter branch - but adding
>>> without cc mode here)
>>> - c
>>> - c++
>>> - java
>>> - css
>>> - JSON
>>> - TypeScript (left out, as it is in tree-sitter branch already)
>> 
>> Cool!
>> 
>>> 
>>> So - some notes:
>>> 
>>> 1. This is still very early, but I wanted to put it out there so that
>>> others more knowledgeable than me could chime in on some of the
>>> languages. C++ in particular is a language I don't code in, and is
>>> notoriously complex.
>>> 
>>> 2. I've focused mostly on indentation and font locking.  Indentation is
>>> using xdisp code style and the gnu style in general.
>>> 
>>> 3. There's some support for navigation
>>> 
>>> 4. I'll make Imenu, which-func and other goodies later.  I want it to be
>>> usable first.
>> 
>> I learnt this from João: you don’t need to write a dedicated which-func function, it by default uses data from Imenu.
>> 
> 
> Nice! I'll check it out.
>>> 
>>> 5. Most other CC mode features such as electric-foo and whitespace
>>> cleanup should be possible to do with constructs outside of cc mode.
>> 
>> Didn’t know cc-mode has white-space cleaning, I’ve always used ws-butler. 
>> 
> 
> It has some hungry delete and similar stuff
> 
>>> 
>>> When scrolling through xdisp with this variant of C support it is
>>> noticeably faster on my system.  However, I'd like some guidance on how
>>> to provide some benchmarks to prove my guess.  Loading said file and
>>> immediately going to EOB is instant, but in CC Mode takes a little less
>>> than a second.
>> 
>> I’ve done benchmarks, and tree-sitter is indeed much faster, you can probably find them in the archive. Speaking of archive, how does you guys find old messages in the archive? The search feature on the official archive webpage is unusable.
>> 
> 
> Yeah, i tried too, hehe.
> 
>>> @Stefan, you mentioned that filling could be extracted from cc
>>> mode. Could you point me either to what/where to look for/at, so that I
>>> can make such an attempt?
>> 
>> I’ll add that it might be a good idea to take out the whole comment, insert them into a temp buffer, fill it with c-fill-paragraph or whatever, then go back and replace the whole comment in the original buffer. Cc-mode’s filling does a lot of invisible insertion and edits in-place, and IIRC it caused problems with eglot before.
>> 
> 
> Yeah, i was hoping that tree-sitter could do that, but I only tried briefly. Seems most of the (comment) nodes contain the comment prefix along with the commented text. Would be nice to access the text without comment prefix, but I guess we can code or way out of that.
> 
> 
> 
> Btw, Yuan - could you tweak indent-region to that it doesn't insert spaces in empty lines? It creates a lot of whitespace changes now :)

Ahhh yes. I’ve change it to not indent empty lines.

Yuan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

>> Btw, Yuan - could you tweak indent-region to that it doesn't insert spaces in empty lines? It creates a lot of whitespace changes now :)
>
>Ahhh yes. I’ve change it to not indent empty lines.
>
>Yuan

Great! Thanks!

Re: CC Mode -> Tree sitter challenge

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eli Zaretskii <eliz@gnu.org>, casouri@gmail.com, Stefan Monnier
>  <monnier@iro.umontreal.ca>
> Date: Fri, 04 Nov 2022 21:34:18 +0100
> 
> 
> Hi Eli and others!
> 
> So you challenged me to add some more modes that are supported in CC
> Mode, but not using CC Mode.  I finally got some free hours, so here's
> my first follow-up to your "show me the code".
> 
> In this repo[0] you will find support for the following modes:
> 
> - javascript  (this is already in tree-sitter branch - but adding
>   without cc mode here)
> - c
> - c++
> - java
> - css
> - JSON
> - TypeScript (left out, as it is in tree-sitter branch already)

Thanks.

> 2. I've focused mostly on indentation and font locking.  Indentation is
> using xdisp code style and the gnu style in general.

We should ideally support all the indentation styles supported by CC
Mode.

> When scrolling through xdisp with this variant of C support it is
> noticeably faster on my system.  However, I'd like some guidance on how
> to provide some benchmarks to prove my guess.

We usually use something like the below:

  (defun scroll-up-benchmark ()
    (interactive)
    (let ((oldgc gcs-done)
	  (oldtime (float-time)))
      (condition-case nil (while t (scroll-up) (redisplay))
	(error (message "GCs: %d Elapsed time: %f seconds"
			(- gcs-done oldgc) (- (float-time) oldtime))))))

  (defun scroll-up-by-40-benchmark ()
    (interactive)
    (let ((oldgc gcs-done)
	  (oldtime (float-time)))
      (condition-case nil (while t (scroll-up 40) (redisplay))
	(error (message "GCs: %d Elapsed time: %f seconds"
			(- gcs-done oldgc) (- (float-time) oldtime))))))

The instructions are: visit xdisp.c and immediately invoke one of
these two functions; then record the time it took to scroll through
the entire file.  Compare to CC Mode.

I think we also want to see the above modified to make some change to
the buffer once in a while.  For example, once in 100 lines insert a
quote ", or a /* followed by */ after several lines, and see how that
affects the scroll times with both modes.

> Loading said file and immediately going to EOB is instant, but in CC
> Mode takes a little less than a second.

Timing this with benchmark-run and presenting the numbers is also
interesting.

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Hi Eli,

[...]

>> - TypeScript (left out, as it is in tree-sitter branch already)
>
> Thanks.

My pleasure.

>> 2. I've focused mostly on indentation and font locking.  Indentation is
>> using xdisp code style and the gnu style in general.
>
> We should ideally support all the indentation styles supported by CC
> Mode.
>

Yes, I'll try to be as comprehensive as possible.

>> When scrolling through xdisp with this variant of C support it is
>> noticeably faster on my system.  However, I'd like some guidance on how
>> to provide some benchmarks to prove my guess.
>
> We usually use something like the below:

Thanks, I used them, see results below.

> The instructions are: visit xdisp.c and immediately invoke one of
> these two functions; then record the time it took to scroll through
> the entire file.  Compare to CC Mode.
>
> I think we also want to see the above modified to make some change to
> the buffer once in a while.  For example, once in 100 lines insert a
> quote ", or a /* followed by */ after several lines, and see how that
> affects the scroll times with both modes.
>
>> Loading said file and immediately going to EOB is instant, but in CC
>> Mode takes a little less than a second.
>
> Timing this with benchmark-run and presenting the numbers is also
> interesting.

So this is the code with results thus far.  It is immediately apparent
how much faster this is, IMO.  Every test is run from a fresh `emacs
-Q`.  I just eval the files, enable the modes and run the tests.

What do you think?  Is there anything clearly wrong with the benchmarks?
In many of the cases tree-sitter is an order of magnitude faster.

```
(defun scroll-up-benchmark ()
  (interactive)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (scroll-up) (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))

(defun scroll-up-by-40-benchmark ()
  (interactive)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (scroll-up 40) (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))

(defun scroll-up-insert-quote-benchmark ()
  (interactive)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil
        (while t
          (scroll-up 50)
          (when (zerop (mod (1- (line-number-at-pos)) 100))
            (insert "\""))
          (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))


(defun xdisp-eob-benchmark ()
  (benchmark-run 100
    (progn
      (with-current-buffer (find-file "~/src/emacs/src/xdisp.c")
	(end-of-buffer))
      (kill-buffer "xdisp.c"))))

;; C-MODE
;; scroll-up-benchmark
;; 1: GCs: 402 Elapsed time: 17.499269 seconds
;; 2: GCs: 415 Elapsed time: 17.789382 seconds

;; scroll-up-by-40-benchmark
;; 1: GCs: 420 Elapsed time: 19.183639 seconds
;; 2: GCs: 420 Elapsed time: 19.377480 seconds

;; xdisp-eob-benchmark 100
;; 1: (40.992420494 1708 16.708356162)
;; 2: (40.630712261 1711 16.361947911999998)

;; xdisp-eob-benchmark 1
;; 1: (0.482883063 21 0.19676500600000002)
;; 2: (0.478595514 21 0.19573110300000002)

;; scroll-up-insert-quote-benchmark
;; 1: GCs: 558 Elapsed time: 41.747822 seconds
;; 2: GCs: 557 Elapsed time: 41.976805 seconds


;; C-TS-MODE
;; scroll-up-benchmark
;; 1: GCs: 21 Elapsed time: 6.997570 seconds
;; 2: GCs: 27 Elapsed time: 7.239952 seconds

;; scroll-up-by-40-benchmark
;; 1: GCs: 30 Elapsed time: 8.869021 seconds
;; 2: GCs: 29 Elapsed time: 9.076617 seconds

;; xdisp-eob-benchmark 100
;; 1: (15.083917789 20 1.1350005760000001)
;; 2: (15.213992551999999 21 1.121564519)

;; xdisp-eob-benchmark 1
;; 1: (0.19189711499999998 1 0.011011572999999997)
;; 2: (0.185749092 1 0.011173242)

;; scroll-up-insert-quote-benchmark
;; 1: GCs: 29 Elapsed time: 15.450495 seconds
;; 2: GCs: 29 Elapsed time: 12.168593 seconds
```

Theo

Re: CC Mode -> Tree sitter challenge

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
> Date: Sat, 05 Nov 2022 14:12:14 +0100
> 
> So this is the code with results thus far.  It is immediately apparent
> how much faster this is, IMO.  Every test is run from a fresh `emacs
> -Q`.  I just eval the files, enable the modes and run the tests.
> 
> What do you think?

Looks very promising, thanks.

> Is there anything clearly wrong with the benchmarks?

I hope not ;-)

> In many of the cases tree-sitter is an order of magnitude faster.

Only in the "go-to-EOB" one, it looks like?  in the others it is 3
times faster on the average, or what did I miss?

How about benchmarking indentation?  E.g., how long does it take to
re-indent a large enough function when you add, say, 'if {' at the
beginning and '}' at the end?

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 5 November 2022 14:31:44 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
>> Date: Sat, 05 Nov 2022 14:12:14 +0100
>> 
>> So this is the code with results thus far.  It is immediately apparent
>> how much faster this is, IMO.  Every test is run from a fresh `emacs
>> -Q`.  I just eval the files, enable the modes and run the tests.
>> 
>> What do you think?
>
>Looks very promising, thanks.
>
>> Is there anything clearly wrong with the benchmarks?
>
>I hope not ;-)
>
>> In many of the cases tree-sitter is an order of magnitude faster.
>
>Only in the "go-to-EOB" one, it looks like?  in the others it is 3
>times faster on the average, or what did I miss?

You're right, but I counted number of gcs as well when making that statement. 

>
>How about benchmarking indentation?  E.g., how long does it take to
>re-indent a large enough function when you add, say, 'if {' at the
>beginning and '}' at the end?

Sure - or even better, how about just knocking every line of xdisp to col 0, C-x h C-i?

I'll do both.

Theo

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Hi again, Eli

> Only in the "go-to-EOB" one, it looks like?  in the others it is 3
> times faster on the average, or what did I miss?
>
> How about benchmarking indentation?  E.g., how long does it take to
> re-indent a large enough function when you add, say, 'if {' at the
> beginning and '}' at the end?

I took the function 'note_mouse_highlight' from xdisp.c, pushed all
lines to column 0 and ran:

Keep in mind that the indentation result is not 100% identical, but I
doubt that will change anything. I'll benchmark everything again when
we're satisfied with the behavior.  This is only 2 evenings worth of
hacking.

(defun xdisp-indent-benchmark (mode)
  (benchmark-run 10
    (progn
      (with-current-buffer (find-file "~/src/tree-sitter-modes/xdispfun.c")
        (funcall mode)
	      (mark-whole-buffer)
        (indent-for-tab-command)
        (undo))
      (kill-buffer "xdispfun.c"))))

;; C-MODE
;; xdisp-indent-benchmark
;; 1: (14.323358754000001 898 7.6331590500000015)
;; 2: (14.027956779 900 7.438876509)
;; 3: (13.631917978 904 7.006082581)

;; C-TS-MODE
;; xdisp-indent-benchmark
;; 1: (9.498073303 54 0.5114733610000002)
;; 2: (9.538100720000001 53 0.5083722219999984)
;; 3: (9.554900124000001 54 0.5174992560000007)


-- 
Theo

Re: CC Mode -> Tree sitter challenge

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
> Date: Sat, 05 Nov 2022 15:37:58 +0100
> 
> I took the function 'note_mouse_highlight' from xdisp.c, pushed all
> lines to column 0 and ran:
> 
> Keep in mind that the indentation result is not 100% identical, but I
> doubt that will change anything.

Why isn't it identical?  Is it because the indentation code is not yet
in its final shape?

> I'll benchmark everything again when we're satisfied with the
> behavior.  This is only 2 evenings worth of hacking.

OK, thanks.  Again, looks good, especially I like how much less GC
this produces.  But note that the, if you subtract the time taken by
GC, CC Mode is actually slightly faster: 6.5 sec vs 9.  I wonder why
is that.

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 5 November 2022 15:55:59 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
>> Date: Sat, 05 Nov 2022 15:37:58 +0100
>> 
>> I took the function 'note_mouse_highlight' from xdisp.c, pushed all
>> lines to column 0 and ran:
>> 
>> Keep in mind that the indentation result is not 100% identical, but I
>> doubt that will change anything.
>
>Why isn't it identical?  Is it because the indentation code is not yet
>in its final shape?
>

Yes, I have to find each case covered by the language and account for it. There's nothing inherent to Yuans code, at least I don't think so. There's still stuff to be done, of course.

>> I'll benchmark everything again when we're satisfied with the
>> behavior.  This is only 2 evenings worth of hacking.
>
>OK, thanks.  Again, looks good, especially I like how much less GC
>this produces.  But note that the, if you subtract the time taken by
>GC, CC Mode is actually slightly faster: 6.5 sec vs 9.  I wonder why
>is that.

Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.

What do you think, Yuan? Any thoughts?

Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)

Theo

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 5 November 2022 16:06:29 CET, Theodor Thornhill <theo@thornhill.no> wrote:
>
>
>On 5 November 2022 15:55:59 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Theodor Thornhill <theo@thornhill.no>
>>> Cc: emacs-devel@gnu.org, casouri@gmail.com, monnier@iro.umontreal.ca
>>> Date: Sat, 05 Nov 2022 15:37:58 +0100
>>> 
>>> I took the function 'note_mouse_highlight' from xdisp.c, pushed all
>>> lines to column 0 and ran:
>>> 
>>> Keep in mind that the indentation result is not 100% identical, but I
>>> doubt that will change anything.
>>
>>Why isn't it identical?  Is it because the indentation code is not yet
>>in its final shape?
>>
>
>Yes, I have to find each case covered by the language and account for it. There's nothing inherent to Yuans code, at least I don't think so. There's still stuff to be done, of course.
>
>>> I'll benchmark everything again when we're satisfied with the
>>> behavior.  This is only 2 evenings worth of hacking.
>>
>>OK, thanks.  Again, looks good, especially I like how much less GC
>>this produces.  But note that the, if you subtract the time taken by
>>GC, CC Mode is actually slightly faster: 6.5 sec vs 9.  I wonder why
>>is that.
>
>Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.
>
>What do you think, Yuan? Any thoughts?
>
>Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)
>

Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)


>Theo
>

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Hi again, Eli!

>>
>>Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.
>>
>>What do you think, Yuan? Any thoughts?
>>
>>Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)
>>
>
> Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)
>

Yes, that was the issue.  Now the scores are as follows:


;; C-MODE
;; scroll-up-benchmark
;; 1: GCs: 402 Elapsed time: 17.499269 seconds
;; 2: GCs: 415 Elapsed time: 17.789382 seconds

;; scroll-up-by-40-benchmark
;; 1: GCs: 420 Elapsed time: 19.183639 seconds
;; 2: GCs: 420 Elapsed time: 19.377480 seconds

;; xdisp-eob-benchmark 100
;; 1: (40.992420494 1708 16.708356162)
;; 2: (40.630712261 1711 16.361947911999998)

;; xdisp-eob-benchmark 1
;; 1: (0.482883063 21 0.19676500600000002)
;; 2: (0.478595514 21 0.19573110300000002)

;; scroll-up-insert-quote-benchmark
;; 1: GCs: 558 Elapsed time: 41.747822 seconds
;; 2: GCs: 557 Elapsed time: 41.976805 seconds

;; xdisp-indent-benchmark
;; 1: (14.323358754000001 898 7.6331590500000015)
;; 2: (14.027956779 900 7.438876509)
;; 3: (13.631917978 904 7.006082581)


;; C-TS-MODE
;; scroll-up-benchmark
;; 1: GCs: 21 Elapsed time: 6.997570 seconds
;; 2: GCs: 27 Elapsed time: 7.239952 seconds

;; scroll-up-by-40-benchmark
;; 1: GCs: 30 Elapsed time: 8.869021 seconds
;; 2: GCs: 29 Elapsed time: 9.076617 seconds

;; xdisp-eob-benchmark 100
;; 1: (15.083917789 20 1.1350005760000001)
;; 2: (15.213992551999999 21 1.121564519)

;; xdisp-eob-benchmark 1
;; 1: (0.19189711499999998 1 0.011011572999999997)
;; 2: (0.185749092 1 0.011173242)

;; scroll-up-insert-quote-benchmark
;; 1: GCs: 29 Elapsed time: 15.450495 seconds
;; 2: GCs: 29 Elapsed time: 12.168593 seconds

;; xdisp-indent-benchmark
;; 1: (1.253069432 12 0.4284672389999997)
;; 2: (1.35523601 12 0.47415286799999734)
;; 3: (1.416845475 12 0.49072914899999986)

>
>>Theo
>>

-- 
Theo

Re: CC Mode -> Tree sitter challenge

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: casouri@gmail.com, monnier@iro.umontreal.ca
> Date: Sat, 05 Nov 2022 17:38:00 +0100
> 
> > Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)
> >
> 
> Yes, that was the issue.  Now the scores are as follows:

Great, thanks.

Re: CC Mode -> Tree sitter challenge

[Yuan Fu]

> On Nov 5, 2022, at 9:38 AM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> Hi again, Eli!
> 
>>> 
>>> Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.
>>> 
>>> What do you think, Yuan? Any thoughts?
>>> 
>>> Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)
>>> 
>> 
>> Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)
>> 
> 
> Yes, that was the issue.  Now the scores are as follows:

The indentation code has a list of rules, and it runs each rule top-to-bottom until one rules matches, then it uses that rule to determine how much to indent. The ordering of each rule could be tweaked so that most frequent case comes forward. We can also arrange these rules not linearly but in a tree, so if one rules matches/doesn’t match, some other rules can be skipped.

What exactly did you compile? I tried byte-compiling indentation rules before but didn’t see a significant speed-up.

Yuan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 6 November 2022 02:13:14 CET, Yuan Fu <casouri@gmail.com> wrote:
>
>
>> On Nov 5, 2022, at 9:38 AM, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>> 
>> Hi again, Eli!
>> 
>>>> 
>>>> Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.
>>>> 
>>>> What do you think, Yuan? Any thoughts?
>>>> 
>>>> Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)
>>>> 
>>> 
>>> Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)
>>> 
>> 
>> Yes, that was the issue.  Now the scores are as follows:
>
>The indentation code has a list of rules, and it runs each rule top-to-bottom until one rules matches, then it uses that rule to determine how much to indent. The ordering of each rule could be tweaked so that most frequent case comes forward. We can also arrange these rules not linearly but in a tree, so if one rules matches/doesn’t match, some other rules can be skipped.

I think the system as it is now it fine, at least for the time being. But I hold no strong opinions there :)

>
>What exactly did you compile? I tried byte-compiling indentation rules before but didn’t see a significant speed-up.
>
>Yuan

See https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L92

Sometimes when exploring indentation i use rules like this. Usually I try to find other ways after, but I just assumed they weren't perf problems. Apparently they are!

And by the way, i created an anchor like this: 
https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L57

This is nice when you need to just move a token to col 0, such as preproc-directives. Maybe that should be a standard one? It could use the buffer-root-node, but this was so simple and fast that I just did it like that.

What do you think?

Theo

Re: CC Mode -> Tree sitter challenge

[Yuan Fu]

> On Nov 5, 2022, at 11:04 PM, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> 
> On 6 November 2022 02:13:14 CET, Yuan Fu <casouri@gmail.com> wrote:
>> 
>> 
>>> On Nov 5, 2022, at 9:38 AM, Theodor Thornhill <theo@thornhill.no> wrote:
>>> 
>>> 
>>> Hi again, Eli!
>>> 
>>>>> 
>>>>> Interesting. My guess is that there are still some improvement possible in the indent-region code, considering that part of treesit.el is quite new.
>>>>> 
>>>>> What do you think, Yuan? Any thoughts?
>>>>> 
>>>>> Anyways, I'll keep working on this and see how far I get next coming weeks. At least in performance it seems I have a good thing going here :-)
>>>>> 
>>>> 
>>>> Thinking of it, some of the indentation questions isn't compiled. I'll run it again later when they are compiled as well :-)
>>>> 
>>> 
>>> Yes, that was the issue.  Now the scores are as follows:
>> 
>> The indentation code has a list of rules, and it runs each rule top-to-bottom until one rules matches, then it uses that rule to determine how much to indent. The ordering of each rule could be tweaked so that most frequent case comes forward. We can also arrange these rules not linearly but in a tree, so if one rules matches/doesn’t match, some other rules can be skipped.
> 
> I think the system as it is now it fine, at least for the time being. But I hold no strong opinions there :)

Yeah if there is no performance issue, it’s better to keep things simple.

>> 
>> What exactly did you compile? I tried byte-compiling indentation rules before but didn’t see a significant speed-up.
>> 
>> Yuan
> 
> See https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L92
> 
> Sometimes when exploring indentation i use rules like this. Usually I try to find other ways after, but I just assumed they weren't perf problems. Apparently they are!

I see, we can precompile these queries automatically for the user. 

> 
> And by the way, i created an anchor like this: 
> https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L57
> 
> This is nice when you need to just move a token to col 0, such as preproc-directives. Maybe that should be a standard one? It could use the buffer-root-node, but this was so simple and fast that I just did it like that.
> 
> What do you think?

I’ll add it, thanks!

Yuan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

Hi Yuan.

>>> The indentation code has a list of rules, and it runs each rule
>>> top-to-bottom until one rules matches, then it uses that rule to
>>> determine how much to indent. The ordering of each rule could be
>>> tweaked so that most frequent case comes forward. We can also
>>> arrange these rules not linearly but in a tree, so if one rules
>>> matches/doesn’t match, some other rules can be skipped.
>> 
>> I think the system as it is now it fine, at least for the time
>> being. But I hold no strong opinions there :)
>
> Yeah if there is no performance issue, it’s better to keep things simple.
>
>>> 
>>> What exactly did you compile? I tried byte-compiling indentation rules before but didn’t see a significant speed-up.
>>> 
>>> Yuan
>> 
>> See https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L92
>> 
>> Sometimes when exploring indentation i use rules like this. Usually I
>> try to find other ways after, but I just assumed they weren't perf
>> problems. Apparently they are!
>
> I see, we can precompile these queries automatically for the user. 
>

I think that's a good idea

>> 
>> And by the way, i created an anchor like this:
>> https://git.sr.ht/~theo/tree-sitter-modes/tree/master/item/c-ts-mode.el#L57
>> 
>> This is nice when you need to just move a token to col 0, such as
>> preproc-directives. Maybe that should be a standard one? It could use
>> the buffer-root-node, but this was so simple and fast that I just did
>> it like that.
>> 
>> What do you think?
>
> I’ll add it, thanks!

My pleasure :)


Come to think of it.  Maybe also some "this should always be fixed at
column N"?

-- 
Theo

Re: CC Mode -> Tree sitter challenge

[Stefan Monnier]

> We usually use something like the below:
>
>   (defun scroll-up-benchmark ()
>     (interactive)
>     (let ((oldgc gcs-done)
> 	  (oldtime (float-time)))
>       (condition-case nil (while t (scroll-up) (redisplay))
> 	(error (message "GCs: %d Elapsed time: %f seconds"
> 			(- gcs-done oldgc) (- (float-time) oldtime))))))
>
>   (defun scroll-up-by-40-benchmark ()
>     (interactive)
>     (let ((oldgc gcs-done)
> 	  (oldtime (float-time)))
>       (condition-case nil (while t (scroll-up 40) (redisplay))
> 	(error (message "GCs: %d Elapsed time: %f seconds"
> 			(- gcs-done oldgc) (- (float-time) oldtime))))))

See also the `elisp-benchmark` package, especially its
`benchmarks/elb-scroll.el` which shows how to do that in batch mode.

We could tweak that file to define not just `elb-scroll-entry` but also
`elb-cc-scroll-entry` to compare the time between the use of
`elb-smie-mode` (whose purpose is not to show how it compares to
CC-mode's C mode but rather to have a non-varying code across Emacs
versions, so we can see the effect of other factors than the mode
itself) and CC-mode's `c-mode` and another using your new `c-mode`.


        Stefan

Re: CC Mode -> Tree sitter challenge

[Theodor Thornhill]

On 5 November 2022 15:34:25 CET, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> We usually use something like the below:
>>
>>   (defun scroll-up-benchmark ()
>>     (interactive)
>>     (let ((oldgc gcs-done)
>> 	  (oldtime (float-time)))
>>       (condition-case nil (while t (scroll-up) (redisplay))
>> 	(error (message "GCs: %d Elapsed time: %f seconds"
>> 			(- gcs-done oldgc) (- (float-time) oldtime))))))
>>
>>   (defun scroll-up-by-40-benchmark ()
>>     (interactive)
>>     (let ((oldgc gcs-done)
>> 	  (oldtime (float-time)))
>>       (condition-case nil (while t (scroll-up 40) (redisplay))
>> 	(error (message "GCs: %d Elapsed time: %f seconds"
>> 			(- gcs-done oldgc) (- (float-time) oldtime))))))
>
>See also the `elisp-benchmark` package, especially its
>`benchmarks/elb-scroll.el` which shows how to do that in batch mode.
>
>We could tweak that file to define not just `elb-scroll-entry` but also
>`elb-cc-scroll-entry` to compare the time between the use of
>`elb-smie-mode` (whose purpose is not to show how it compares to
>CC-mode's C mode but rather to have a non-varying code across Emacs
>versions, so we can see the effect of other factors than the mode
>itself) and CC-mode's `c-mode` and another using your new `c-mode`.
>
>
>        Stefan
>

Thanks! I'll check it out

Theo