Subject: bug#41242: Port feature/native-comp to Windows - Improve handling of native compilation...

From: Nicolas Bértolo <[email-masked]>
Date: Sun, 24 May 2020 16:43:11 -0300

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 (<[email-masked]>) escribió:

> Nicolas Bértolo <[email-masked]> 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
>
> --
> [email-masked]
>