unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Some performance questions.
       [not found] <20230208190819.z7xwgxm5gpbzmjrz.ref@Ergus>
@ 2023-02-08 19:08 ` Ergus
  2023-02-08 20:09   ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Ergus @ 2023-02-08 19:08 UTC (permalink / raw)
  To: emacs-devel; +Cc: Eli Zaretskii

Hi:

I have been forced to use emacs in MS-Windows and after some days
tweaking and trying I have some comments I am not sure if they are
intended, known or issues. So, I ask before creating a bug report.

I am making this comments now because I have exactly the same config on
GNU/Linux and I don't have any issue.

1) I observed important lags and delays interactively (moving cursor,
scrolling or just editing simple C++ code).

I ran the profiler and I found that 50% of the time was consumed by
flycheck's hooks. As I know flycheck is not our business, I disabled it
and continued.

2) While much better; there is still a very annoying lag. If I type
fast, the letters don't appear in the screen immediately, but come all
together after a while.

Again profile-start and this time I found that in a simple test like
editing (type, delete words, write functions), 35% of the time was consumed
by the garbage collection (Automatic GC) and other 35% by flyspell.

- So I checked the gcs-done variable and the value was not specially
different than same test on GNU/Linux.. but the time percent was much
higher.

- I disabled the flyspell for the moment as I have no other choice.

3) Now, in spite of it is much better, still there is a significant lag
(compared with GNU/Linux) which concerns me about whats going on with
the GC.

Now I get in the profiler-report:

71 45% Automatic GC
68 43% redisplay_internal
         jit-lock-function
             ...
             font-lock-fontify-keywords-region

37 23%          c-font-lock-declarations
20 12%          c-font-lock-cut-off-declarators

I have not observed such lags before on GNU/Linux, so some idea what I
may be doing wrong?

I know Eli uses MS-Windows frequently, so, any hint?

Thanks in advance,
Ergus



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-08 19:08 ` Some performance questions Ergus
@ 2023-02-08 20:09   ` Eli Zaretskii
  2023-02-08 20:15     ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-02-08 20:09 UTC (permalink / raw)
  To: Ergus; +Cc: emacs-devel

> Date: Wed, 8 Feb 2023 20:08:19 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> 3) Now, in spite of it is much better, still there is a significant lag
> (compared with GNU/Linux) which concerns me about whats going on with
> the GC.
> 
> Now I get in the profiler-report:
> 
> 71 45% Automatic GC
> 68 43% redisplay_internal
>          jit-lock-function
>              ...
>              font-lock-fontify-keywords-region
> 
> 37 23%          c-font-lock-declarations
> 20 12%          c-font-lock-cut-off-declarators
> 
> I have not observed such lags before on GNU/Linux, so some idea what I
> may be doing wrong?
> 
> I know Eli uses MS-Windows frequently, so, any hint?

Try using c-ts-mode instead (assuming this is Emacs 29 and it was
built with tree-sitter).



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-08 20:09   ` Eli Zaretskii
@ 2023-02-08 20:15     ` Eli Zaretskii
  2023-02-08 20:56       ` Ergus
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-02-08 20:15 UTC (permalink / raw)
  To: spacibba; +Cc: emacs-devel

> Date: Wed, 08 Feb 2023 22:09:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > 71 45% Automatic GC
> > 68 43% redisplay_internal
> >          jit-lock-function
> >              ...
> >              font-lock-fontify-keywords-region
> > 
> > 37 23%          c-font-lock-declarations
> > 20 12%          c-font-lock-cut-off-declarators
> > 
> > I have not observed such lags before on GNU/Linux, so some idea what I
> > may be doing wrong?
> > 
> > I know Eli uses MS-Windows frequently, so, any hint?
> 
> Try using c-ts-mode instead (assuming this is Emacs 29 and it was
> built with tree-sitter).

And if you cannot use tree-sitter, then try this:

  (setq jit-lock-stealth-time 16)
  (setq jit-lock-defer-contextually t)
  (setq jit-lock-stealth-load 20)



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-08 20:15     ` Eli Zaretskii
@ 2023-02-08 20:56       ` Ergus
  2023-02-09  6:17         ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Ergus @ 2023-02-08 20:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

Hi Eli:

Thanks for replying. Is the GC also improved by tree-sitter? Because it is taking a significant  part of the time, as you can see in my first mail.

Thanks, 
Ergus




On February 8, 2023 9:15:11 PM GMT+01:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 08 Feb 2023 22:09:36 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > 71 45% Automatic GC
>> > 68 43% redisplay_internal
>> >          jit-lock-function
>> >              ...
>> >              font-lock-fontify-keywords-region
>> > 
>> > 37 23%          c-font-lock-declarations
>> > 20 12%          c-font-lock-cut-off-declarators
>> > 
>> > I have not observed such lags before on GNU/Linux, so some idea what I
>> > may be doing wrong?
>> > 
>> > I know Eli uses MS-Windows frequently, so, any hint?
>> 
>> Try using c-ts-mode instead (assuming this is Emacs 29 and it was
>> built with tree-sitter).
>
>And if you cannot use tree-sitter, then try this:
>
>  (setq jit-lock-stealth-time 16)
>  (setq jit-lock-defer-contextually t)
>  (setq jit-lock-stealth-load 20)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1864 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-08 20:56       ` Ergus
@ 2023-02-09  6:17         ` Eli Zaretskii
  2023-02-09 13:14           ` Ergus
       [not found]           ` <20230209114928.eqpojruluur42hur@Ergus>
  0 siblings, 2 replies; 8+ messages in thread
From: Eli Zaretskii @ 2023-02-09  6:17 UTC (permalink / raw)
  To: Ergus; +Cc: emacs-devel

> Date: Wed, 08 Feb 2023 21:56:31 +0100
> From: Ergus <spacibba@aol.com>
> CC: emacs-devel@gnu.org
> 
> Thanks for replying. Is the GC also improved by tree-sitter? Because it is taking a significant  part of the
> time, as you can see in my first mail.

Tree-sitter based modes do less processing in Lisp (the buffer parsing
is doen by the tree-sitter and the grammar libraries, entirely in C
and C++), so they should in general produce less garbage and require
less GC, yes.

Turning on jit-stealth also lowers the GC pressure because it
fontifies buffers during idle time, so by the time you get to actually
editing a buffer it is already fontified, and thus all the garbage
produced by fontifications was already produced and collected; the
editing itself will produce much less garbage.

Finally, I see that in my customizations I increase gc-cons-threshold
to 1800000 (from the default of 800000), so maybe try that as well.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-09  6:17         ` Eli Zaretskii
@ 2023-02-09 13:14           ` Ergus
       [not found]           ` <20230209114928.eqpojruluur42hur@Ergus>
  1 sibling, 0 replies; 8+ messages in thread
From: Ergus @ 2023-02-09 13:14 UTC (permalink / raw)
  To: emacs-devel

On Thu, Feb 09, 2023 at 08:17:37AM +0200, Eli Zaretskii wrote:
>> Date: Wed, 08 Feb 2023 21:56:31 +0100
>> From: Ergus <spacibba@aol.com>
>> CC: emacs-devel@gnu.org
>>
>> Thanks for replying. Is the GC also improved by tree-sitter? Because it is taking a significant  part of the
>> time, as you can see in my first mail.
>
>Tree-sitter based modes do less processing in Lisp (the buffer parsing
>is doen by the tree-sitter and the grammar libraries, entirely in C
>and C++), so they should in general produce less garbage and require
>less GC, yes.
>
>Turning on jit-stealth also lowers the GC pressure because it
>fontifies buffers during idle time, so by the time you get to actually
>editing a buffer it is already fontified, and thus all the garbage
>produced by fontifications was already produced and collected; the
>editing itself will produce much less garbage.
>
>Finally, I see that in my customizations I increase gc-cons-threshold
>to 1800000 (from the default of 800000), so maybe try that as well.
>

Hi Eli:

Very very thanks for the hints. ATM I'll stay with cc-mode and the other
suggestions you did due to the next comments.

(I know it is a WIP, probably some of these comments are not issues, but
just need a bit more details in the documentation... and I am dumb)

1) The new c-ts-mode-indent-style is a bit confusing for a cc-mode
user..., 

could you add some similar/equivalent examples than the ones in the
cc-mode documentation in order to extrapolate/translate? 

   OR

Is it possible to use add examples of equivalent implementations between
c-offsets-alist and c-ts-mode-indent-style.

2) In case the user wants to modify an indentation style, is it possible
to use another existing style and use it as base template like
c-add-style does?

3) Which of the cc-hooks (c-hanging-braces-alist, c-cleanup-list and
c-hanging-semi&comma-criteria) is already possible to reproduce with ts?
some example please :(

4) Is it possible already (I am sure that in the future they will), to
create behaviors like c-lineup-arglist,
c-lineup-arglist-intro-after-paren, or c-snug-do-while?

I had some other small issues here and there (one of them I reported,
the others I will do once I assert are not mistakes in my config).

Best and thanks,
Ergus



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
       [not found]           ` <20230209114928.eqpojruluur42hur@Ergus>
@ 2023-02-09 13:46             ` Eli Zaretskii
  2023-02-09 15:45               ` Ergus
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2023-02-09 13:46 UTC (permalink / raw)
  To: Ergus; +Cc: emacs-devel

> Date: Thu, 9 Feb 2023 12:49:28 +0100
> From: Ergus <spacibba@aol.com>
> 
> 1) The new c-ts-mode-indent-style is a bit confusing for a cc-mode
> user..., 

That is strange, since it's supposed to support (a subset of) the same
styles that CC mode support, including the default GNU style.

> could you add some similar/equivalent examples than the ones in the
> cc-mode documentation in order to extrapolate/translate? 
> 
>   OR
> 
> Is it possible to use add examples of equivalent implementations between
> c-offsets-alist and c-ts-mode-indent-style.

This is supposed to work via indentation styles, see below.

> 2) In case the user wants to modify an indentation style, is it possible
> to use another existing style and use it as base template like
> c-add-style does?

See c-ts-mode-set-style (bound to "C-c .", as in CC mode) and
c-ts-mode-set-global-style.

> 3) Which of the cc-hooks (c-hanging-braces-alist, c-cleanup-list and
> c-hanging-semi&comma-criteria) is already possible to reproduce with ts?
> some example please :(

Please describe the behavior you want to see and didn't see in
c-ts-mode, the CC mode variables are not used in c-ts-mode.

> 4) Is it possible already (I am sure that in the future they will), to
> create behaviors like c-lineup-arglist,
> c-lineup-arglist-intro-after-paren, or c-snug-do-while?

Again, please request features.  I'm not sure I even know what these
do.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Some performance questions.
  2023-02-09 13:46             ` Eli Zaretskii
@ 2023-02-09 15:45               ` Ergus
  0 siblings, 0 replies; 8+ messages in thread
From: Ergus @ 2023-02-09 15:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Hi Eli:

On Thu, Feb 09, 2023 at 03:46:49PM +0200, Eli Zaretskii wrote:
>> Date: Thu, 9 Feb 2023 12:49:28 +0100
>> From: Ergus <spacibba@aol.com>
>>
>> 1) The new c-ts-mode-indent-style is a bit confusing for a cc-mode
>> user...,
>
>That is strange, since it's supposed to support (a subset of) the same
>styles that CC mode support, including the default GNU style.
>
Yes, but in cc-mode it was possible (and pretty simple) to modify or
create new styles. There are plenty of styles around modifying existing
ones (google-c-style for example).

In the new ts-mode looks like it is possible to do so, but the syntax
and the names are a bit tricky. For example in cc-mode there was the
c-set-offset command, very useful for small changes and to know which
indentation syntactic element was at point. So with that information the
user only needs:

(c-offsets-alist (inline-open . 0)
		 (arglist-close . 0)
		 (innamespace . [0])
		 (access-label '-)
		 )

to increase, decrease or set the indentation to zero.

That's why just some equivalences or examples may be very helpful to
ease the transition.

>> could you add some similar/equivalent examples than the ones in the
>> cc-mode documentation in order to extrapolate/translate?
>>
>>   OR
>>
>> Is it possible to use add examples of equivalent implementations between
>> c-offsets-alist and c-ts-mode-indent-style.
>
>This is supposed to work via indentation styles, see below.
>
The idea is to modify one of the existing styles or create new ones. Se
above

>> 2) In case the user wants to modify an indentation style, is it possible
>> to use another existing style and use it as base template like
>> c-add-style does?
>
>See c-ts-mode-set-style (bound to "C-c .", as in CC mode) and
>c-ts-mode-set-global-style.
>
I mean, tweak details... like the inheritance we do in c-add-style, not
set a completely different one.

(c-add-style "mylinux"
	       '("linux"              <-
		 (tab-width . 4)
		 (c-basic-offset . 4)
                  (fill-column . 80)
                  ...

>> 3) Which of the cc-hooks (c-hanging-braces-alist, c-cleanup-list and
>> c-hanging-semi&comma-criteria) is already possible to reproduce with ts?
>> some example please :(
>
>Please describe the behavior you want to see and didn't see in
>c-ts-mode, the CC mode variables are not used in c-ts-mode.
>
I know they are not. I asked for some kind of equivalence (if available)
because I don't know if they were already implemented somehow.

c-hanging-braces-alist: Controls the insertion of newlines before and after braces

c-cleanup-list: Basically for the opposite, to remove some auto inserted
new lines next to braces (for example to have things like '} else {' or
'{}')

c-hanging-semi&comma-criteria For a similar behavior but with
semi-colons and other cases.

>> 4) Is it possible already (I am sure that in the future they will), to
>> create behaviors like c-lineup-arglist,
>> c-lineup-arglist-intro-after-paren, or c-snug-do-while?
>
>Again, please request features.  I'm not sure I even know what these
>do.

Thanks. I will do, but there are multiple things and I don't want to be
too (even more) pedantic, so I one by one...

Best,
Ergus




^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-02-09 15:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20230208190819.z7xwgxm5gpbzmjrz.ref@Ergus>
2023-02-08 19:08 ` Some performance questions Ergus
2023-02-08 20:09   ` Eli Zaretskii
2023-02-08 20:15     ` Eli Zaretskii
2023-02-08 20:56       ` Ergus
2023-02-09  6:17         ` Eli Zaretskii
2023-02-09 13:14           ` Ergus
     [not found]           ` <20230209114928.eqpojruluur42hur@Ergus>
2023-02-09 13:46             ` Eli Zaretskii
2023-02-09 15:45               ` Ergus

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).