Re: igc, macOS avoiding signals

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> 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>

(I have a crazy idea for that, too.  Code, too.  But it does away with
the gap buffer, which the regexp code assumes, so we end up creating a
shadow single-string buffer whenever we call into the regexp code, which
is, er, slow.)

>> 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.

I did implement a Lisp variable as well (defaulting it to on because I'm
more conservative than you are :-) ).  I still think it's more likely
it's (also) a bug elsewhere: balancing a tree for an 8 MB buffer should
not take long.

I am currently not calling compact_buffer when the variable is off.
Maybe that's something to look into, too.

In my current session, keypresses (with idle time in between, because I
can't outtype Emacs) become noticeably laggy if I set the variable to t,
but not when it's nil.

Further investigation needed, I think.  Unfortunately, that's going to
require some instrumentation code and then I have to restart my Emacs
session...

Pip