Re: igc, macOS avoiding signals

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Pip Cet <pipcet@protonmail.com> writes:

> Speaking of running with a "normal" config: something about my
> configuration makes buffer_step (the balance_intervals call, in
> particular) take forever, to the point the mps build becomes unusable.
> The buffer in question, when I caught it, is an M-x shell buffer of size
> 8 MB, so I don't understand why it's taking so long.
>
> Still investigating, but skipping the buffer_step seems to help.

balance_intervals means text properties. The only candidate I see in
comint/shell is ANSI escapes. That could be turned on/off with M-x
ansi-color-for-comint-mode-xy. Only as a workaround, and maybe to check
if it's that.

What I do in buffer_step in idle time is basically one step of what the
old GC does in sweep_buffers.

My expectation was that balancing a tree couldn't take long, and that
this is not called often enough to be a problem if were expensive. Both
wrong, as usual.

Not calling balance_intervals is, BTW, not a catastrophic problem. if
one does anything leading to a graft_intervals_into_buffer, w</r hich is
called in a lot of places in editfns.c and insdel.c, that balances the
tree. And if not, the tree might become slower for lookup (redisplay),
but it still works.

<rant> It's BTW well possible that I myself put that balancing into
sweep_buffers because of redisplay, I seem to remember that. The
interval tree has always been a source of fun. I hope, some day, some
kind soul will eradicate it like the GCPROs. </rant>

In any case, what's a solution?

Right now I'm tending to put the balance_intervals in an if so that one
can turn it on/off with a Lisp variable. Default would be to not to balance,
because I think the problems with degenerated interval trees in
redisplay where rare, and I don't remember problems outside of
redisplay. But that was an awful long time ago, OTOH.

That would give us more time to think about a possible strategy to solve
this.

WDYT?