On Saturday, July 6th, 2024 at 16:31, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> Pip Cet pipcet@protonmail.com writes:
> 
> > I wonder how representative that is of actual workloads, though.
> 
> It isn't, for sure :-).
> 
> > It does appear mostly to be the cost of finalization, if I deactivate
> > that (and leak the memory instead!) it takes about 6.5 seconds on this
> > machine compared to ~9 on my main Emacs. Totally unscientific, of
> > course, I'm pretty sure I even updated my compiler since compiling
> > vanilla Emacs. Both use nativecomp.
> 
> I think the same. I under the impression that probably many millions of
> bignums are used, each of which requires inter-thread communication and
> so on. That's quite expensive if true.
> 
> > So IF it's worth optimizing this, the thing to look into would be to
> > use MPS-managed memory for GMP bignums, so we don't need a finalizer
> > at all. I think that's quite easy to do, but requires violating the
> > GMP API by accessing internal member fields directly.
> 
> 
> We have already this in bignum.c
> 
> mp_set_memory_functions (xmalloc, xrealloc_for_gmp, xfree_for_gmp);
> 
> Haven't read the GMP docs yet, but that looks like something that could
> be used.

Patch attached, couldn't resist :-)

Memory usage is perfectly acceptable with this patch, but it does do a lot of GC.

> > I believe Eli is right, though, that we should deviate from what Emacs
> > usually does as little as possible until we've got things working.
> > That means just keeping track of how much we've allocated and calling
> > garbage_collect via maybe_garbage_collect, I think.

> Can you explain? I mean I agree in general, but in this case I'm not so
> sure. What I've currently implemented is basically a function of the
> number of allocated finalizable objects and only finalizable objects pay
> the price. The size of allocated memory overall, i.e. counting the bytes
> in alloc_impl doesn't contain the information.

But it's probably a better indicator of how much GC activity happened, and that influences how many finalization messages there would be, assuming that an approximately constant percentage of objects is finalizable...

Pip