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

[Andrea Corallo]

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