Some experience with the igc branch

Some experience with the igc branch

[Óscar Fuentes]

I've using the igc branch for the past weeks. It was mostly Dart/Flutter
development with lsp-dart / lsp-mode enabled, with all its default
features enabled. On top of that, I use the flx completion algorithm.

This setup puts a lot of stress on GC. To illustrate, on master Emacs
after setting garbage-collection-messages to t, one can see that simply
writing a few characters triggers GC several times, each with its
corresponding pause, which may be very noticeable ("uh! that keypress
didn't register... wait, there it is.") The experience is not great.
Quite miserable, I would say. People suggest playing with
gc-cons-threshold (I have mine set to 10'000'000) but those tricks
simply make things a bit less awful.

With igc the pauses are still there, but they much shorter and
predictable, they no longer distract me from thinking on what I'm
writing, which is a huge improvement. I suspect that some of those
pauses are not related to garbage collection (executing code and moving
data also takes time.)

TL/DR: now I enjoy using Emacs with this setup and I'm no longer tempted
to switch to other editors for this type of work.

A big thank you to all involved on this feature.

Re: Some experience with the igc branch

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I've using the igc branch for the past weeks. It was mostly Dart/Flutter
> development with lsp-dart / lsp-mode enabled, with all its default
> features enabled. On top of that, I use the flx completion algorithm.
>
> This setup puts a lot of stress on GC. To illustrate, on master Emacs
> after setting garbage-collection-messages to t, one can see that simply
> writing a few characters triggers GC several times, each with its
> corresponding pause, which may be very noticeable ("uh! that keypress
> didn't register... wait, there it is.") The experience is not great.
> Quite miserable, I would say. People suggest playing with
> gc-cons-threshold (I have mine set to 10'000'000) but those tricks
> simply make things a bit less awful.
>
> With igc the pauses are still there, but they much shorter and
> predictable, they no longer distract me from thinking on what I'm
> writing, which is a huge improvement. I suspect that some of those
> pauses are not related to garbage collection (executing code and moving
> data also takes time.)
>
> TL/DR: now I enjoy using Emacs with this setup and I'm no longer tempted
> to switch to other editors for this type of work.
>
> A big thank you to all involved on this feature.

👍 

Re: Some experience with the igc branch

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> With igc the pauses are still there, but they much shorter and
> predictable, they no longer distract me from thinking on what I'm
> writing, which is a huge improvement. I suspect that some of those
> pauses are not related to garbage collection (executing code and moving
> data also takes time.)

In my case, with Eglot, the following settings made a difference;

  :custom
  (eglot-sync-connect nil)
  (eglot-events-buffer-config '(:size 0 :format full)))

Don't know if Lsp-mode has similar knobs.

Re: Some experience with the igc branch

[Pip Cet via Emacs development discussions.]

Óscar Fuentes <ofv@wanadoo.es> writes:
> With igc the pauses are still there, but they much shorter and
> predictable, they no longer distract me from thinking on what I'm
> writing, which is a huge improvement. I suspect that some of those
> pauses are not related to garbage collection (executing code and moving
> data also takes time.)

Quite possible.  Even if it is GC, please keep in mind that MPS has many
settings which you can play with, and it can improve things a lot.  It's
not too early to become a fan of the scratch/igc branch, but it is too
early to reject it for performance reasons.  It's a "heads you lose, tails I
win" situation, I guess.

> TL/DR: now I enjoy using Emacs with this setup and I'm no longer tempted
> to switch to other editors for this type of work.

I think this is an important point: ultimately, it's about having daily
drivers.  We need to remove the remaining impediments for that:

1. The signal issue.  I don't have a good way to fix this and make
everyone happy, but I do have a solution which hasn't caused a crash for
me in quite a while.  It may be good enough.

2. no-purespace.  Merging that into scratch/igc would help, well, me.
What do others think?

3. bytecode stack marking.  That comment raises my red-flag alert,
because it sounds like we're just accepting a preventable crash at this
stage rather than wanting to do anything about it.  The reality, of
course, is different, but I'd be happier if we refused to create a byte
code object that intends to use more stack than we can guarantee we
would scan.  Can we do that?

Pip

Re: Some experience with the igc branch

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> 3. bytecode stack marking.  That comment raises my red-flag alert,
> because it sounds like we're just accepting a preventable crash at this
> stage rather than wanting to do anything about it.  The reality, of
> course, is different, but I'd be happier if we refused to create a byte
> code object that intends to use more stack than we can guarantee we
> would scan.  Can we do that?
>
> Pip

You mean my comment here?

static mps_res_t
scan_bc (mps_ss_t ss, void *start, void *end, void *closure)
{
  MPS_SCAN_BEGIN (ss)
  {
    struct igc_thread_list *t = closure;
    struct bc_thread_state *bc = &t->d.ts->bc;
    igc_assert (start == (void *) bc->stack);
    igc_assert (end == (void *) bc->stack_end);
    /* FIXME/igc: AFAIU the current top frame starts at
       bc->fp->next_stack and has a maximum length that is given by the
       bytecode being executed (COMPILED_STACK_DEPTH). So, we need to
       scan upto bc->fo->next_stack + that max depth to be safe.  Since
       I don't have that number ATM, I'm using an arbitrary estimate for
       now.

       This must be changed to something better. Note that Mattias said
       the bc stack marking will be changed in the future.  */
    const size_t HORRIBLE_ESTIMATE = 1024;
    char *scan_end = bc_next_frame (bc->fp);
    scan_end += HORRIBLE_ESTIMATE;
    end = min (end, (void *) scan_end);
    if (end > start)
      IGC_FIX_CALL (ss, scan_ambig (ss, start, end, NULL));
  }
  MPS_SCAN_END (ss);
  return MPS_RES_OK;
}

I never felt like changing the byte code stack, TBH. For reasons :-).

Re: Some experience with the igc branch

[Óscar Fuentes]

Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

>> I suspect that some of those
>> pauses are not related to garbage collection (executing code and moving
>> data also takes time.)
>
> Quite possible.  Even if it is GC, please keep in mind that MPS has many
> settings which you can play with, and it can improve things a lot.  It's
> not too early to become a fan of the scratch/igc branch, but it is too
> early to reject it for performance reasons.  It's a "heads you lose, tails I
> win" situation, I guess.

IIRC MPS is well documented and I can look up those settings, but does
Emacs collect the required info for taking informed decisions?

Anyway, with the setup I'm using for this job is totally unrealistic to
expect instant reaction from Emacs, there is too much heavy stuff
kicking in for every keypress.

> 1. The signal issue.  I don't have a good way to fix this and make
> everyone happy, but I do have a solution which hasn't caused a crash for
> me in quite a while.  It may be good enough.

Inevitably, a few minutes after sending my message Emacs froze after
working flawlessly since you fixed the JSON issue.

Redisplay just stopped while showing the menu, no crash nor infinite
loop, its CPU usage was typical for the repeating timers that my config
creates. Sadly, instead of attaching gdb I tried to wake up Emacs by
sending SIGUSR1 (no effect, as it is the wrong signal, should be
SIGUSR2) and then sent SINGINT by mistake, which terminated the process.

It's very likely that MPS is innocent on this, but I'm happy to apply
and test any stability improvement patch you have and wish to share.

Thanks.

Re: Some experience with the igc branch

[Helmut Eller]

On Sun, Dec 22 2024, Pip Cet wrote:

> 2. no-purespace.  Merging that into scratch/igc would help, well, me.
> What do others think?

No objections from me.

> 3. bytecode stack marking.  That comment raises my red-flag alert,
> because it sounds like we're just accepting a preventable crash at this
> stage rather than wanting to do anything about it.  The reality, of
> course, is different, but I'd be happier if we refused to create a byte
> code object that intends to use more stack than we can guarantee we
> would scan.  Can we do that?

Maybe the bytecode engine could handle large stack frames differently
from small stack frames.

For large stack frames we would:
 1. initialize the stack frame with NULLs
 2. bump the stack pointer
 3. now the stack frame is usable

For small stack frames, we would skip step 1 but the GC would always
scan one extra "small frame with maximal length".

Helmut

Re: Some experience with the igc branch

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> With igc the pauses are still there, but they much shorter and
>> predictable, they no longer distract me from thinking on what I'm
>> writing, which is a huge improvement. I suspect that some of those
>> pauses are not related to garbage collection (executing code and moving
>> data also takes time.)
>
> Quite possible.  Even if it is GC, please keep in mind that MPS has many
> settings which you can play with, and it can improve things a lot.  It's
> not too early to become a fan of the scratch/igc branch, but it is too
> early to reject it for performance reasons.  It's a "heads you lose, tails I
> win" situation, I guess.
>
>> TL/DR: now I enjoy using Emacs with this setup and I'm no longer tempted
>> to switch to other editors for this type of work.
>
> I think this is an important point: ultimately, it's about having daily
> drivers.  We need to remove the remaining impediments for that:
>
> 1. The signal issue.  I don't have a good way to fix this and make
> everyone happy, but I do have a solution which hasn't caused a crash for
> me in quite a while.  It may be good enough.

TBH, I'd have put it in already.

> 2. no-purespace.  Merging that into scratch/igc would help, well, me.
> What do others think?

Doesn't affect me much.