GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Full log

Message #329 received at 41242 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 41242 <at> debbugs.gnu.org
Subject: Re: bug#41242: Port feature/native-comp to Windows - Improve handling
 of native compilation...
Date: Sun, 24 May 2020 19:13:59 +0000

Nicolas Bértolo <nicolasbertolo <at> 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 <at> sdf.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.