Re: MPS: optimized build

[Dmitry Gutov <dmitry@gutov.dev>]

On 06/05/2024 14:49, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>>    Helmut Eller <eller.helmut@gmail.com>
>> Date: Mon, 06 May 2024 09:03:48 +0200
>>
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> On 05/05/2024 09:16, Gerd Möllmann wrote:
>>>> In general, but I guess the wish is the father of the thought as we say
>>>> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
>>>> completions, even typing text maybe?
>>>> Would be interesting to hear from others how they perceive it...
>>>
>>> I've built the branch and done some measurements with
>>>
>>>    (benchmark-run 5 (project-files (project-current)))
>>>
>>> and it seems like the same or a little slower with smaller projects
>>> (less GC-intensive) and a stable improvement, about 5%, in in a larger
>>> one (more GC-intensive). Which seems good.
>>>
>>> I haven't noticed a particular change in snappiness so far, but then I
>>> also don't usually see this problem.
>>
>> Thanks!
>>
>> Interesting anecdote, maybe: I think I mentioned that have an Org file
>> in which GCs happened so often that it was basically unusable. This Org
>> file behaved much much better with MPS. Almost normal.
> 
> Indeed, the comparisons in this case should be against code that
> produces a lot of garbage, not against code that is performance-heavy.

I think when evaluating the change we would consider two questions:

- Does it make non-consing code slower? (Due to more complex object 
accounting, for example, or expensive parallel scanning).
- Does it reduce the time spent in GC when there is indeed garbage to 
collect.

I'd also ask "does it reduce pauses", but this one seems to have been 
already answered, MPS being a concurrent GC. Though there might have 
been some locking issues which could induce pauses anyway.

My scenario above is actually garbage-heavy (lots of strings generated). 
And yet the new GC is the same or slightly slower for smaller project 
scans, but faster on the largest one. Might have to do something with 
the fact that the current GC's thresholds are in absolute values, not 
percentiles of any kind.