Re: MPS: User GC customizations

[Ihor Radchenko]

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

>>>   igc-step-interval is a variable defined in ‘C source code’.
>>> ...
>> IMHO, this variable makes little sense in isolation. It only makes sense
>> to postpone GCs when we also have the means to increase the thresholds
>> when to trigger them. Most of the time, GCs are triggered by
>> memory-intensive commands. Extra GC on idle would not help those.
>
> Define GC, so to speak, and define what triggering the GC means in a
> concurrent, incremental GC :-)

AFAIU, the points of interests from real-time performance perspective
are (1) when MPS has to pause the threads to do its job and how we can
tweak it; (2) how long does it take to scan the arena to allocate new
objects (synchronous process) and how this time is influenced by MPS
settings.

> What this variable does is give MPS notice that the client is currently
> idle and it might be a good time to do some work.

Without understanding what effect setting this variable has on the Emacs
responsiveness, it does not seem very useful. (Exactly because MPS is
concurrent)

>> For example, my recent measurement of building agendas displayed 30% of
>> the time spend in GC. (whatever this means in the context of our handling
>> of SIGPRF)
>
> Exactly, whqt does it mean? And if we don't know, why is it an example
> for anything?

AFAIU, on master, SIGPROF handled while our vanilla GC is running
will record it. In contrast, on scratch/igc, SIGPROF will put all the
time when igc_busy_p () is non-nil into "GC".

And igc_busy_p is not only non-nil when MPS is pausing Emacs to do its
job, but also during object allocation. So, on master, profiler "GC"
field records real GC pauses, while on scratch/igc "GC" field is GC
pauses + new object allocation.

My figure of 30% says that igc_busy_p () is for 30% of CPU time, which
is a significant number. But it is not very useful unless we get some
idea about which part of it is memory allocation and which part of it is
MPS pausing all Emacs threads.

Ideally, we should also have some way to get the allocation times on
master. Then, we can compare them directly.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>