I pushed a new version of the patch to my git repo.

Thanks, Nico

El dom., 24 may. 2020 a las 16:14, Andrea Corallo (<akrl@sdf.org>) escribió:

> Nicolas Bértolo <nicolasbertolo@gmail.com> writes:
>
> >> The problem is that GC is called (especially by default) *very*
> >> frequently, bounding GC performance to filesystem accesses is
> > really not
> >> a good idea IMO because we have no control over this last.
> >>
> >> You could not see a difference here because:
> >>
> >> - spaceemacs GC settings runs it way less often coming with a
> > bigger
> >>   gc-cons-threshold by default
> >>
> >> - GC euristincs being GC slow decides to give-up a little and
> > accept
> >>   running less often leading to more fragmentation
> >>
> >> - filesystem is blazingly fast
> >>
> >> - you haven't measured ;)
> >
> > Actually unloading a native compilation unit is such an unfrequent
> > operation
> > that all that finish_delayed_disposal_of_comp_units() does is compare
> > a pointer
> > to NULL. It will not slowdown the GC at all.
> >
> > Anyway, I could change this to run on an idle timer or just handle it
> > when Emacs
> > closes. Which do you prefer?
>
> What you say is correct, collecting a compilation unit is very
> infrequent now.  But code could decide to native compile functions each
> time a performance critical operation has to be done, real world code
> does that already relying on the byte-compiler.
>
> I think to start with doing the clean-up when Emacs is closing is
> sufficient, we can always add the timer in case we feel the need.
>
> Thanks
>
>   Andrea
>
> --
> akrl@sdf.org
>