emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lisp files that load cl-lib in problematical ways


From: Andrea Corallo
Subject: Re: Lisp files that load cl-lib in problematical ways
Date: Wed, 25 Oct 2023 18:02:52 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo@gnu.org>
>>> Cc: Stephen Berman <stephen.berman@gmx.net>,  incal@dataswamp.org,
>>>   emacs-devel@gnu.org
>>> Date: Thu, 19 Oct 2023 09:44:51 -0400
>>> 
>>> Okay, I confirm that comp.el loads cl-lib, so any jit compilation
>>> triggered loads that.
>>
>> This is OK, not a problem.
>>
>>> OTOH one thing we could do, if that's important, is to split the code
>>> that only drives the async compilation (that actually happens in a
>>> subprocess) so we don't load cl-lib in the Emacs the user is actually
>>> using.  This should not be that hard (optimism mode on).
>>
>> I don't see the need, but I will not object if you want to make such
>> changes.
>
> Okay I'll think about it, might be a positive change even leaving aside
> the cl-lib discussion.

So I did some experimentation (scratch/comp-run branch) where I splitted
the code needed to run the (async) native compiler at runtime into a
separete file (comp-run.el).

I think it's a good change as:

1- instead of loading almost 6000 lines of compiler only code
   (comp.el+comp-cstr.el not including dependencies) a normal user now
   has to load only ~500 LOC.  The rest will be loaded only by the async
   workers.

2- it is conceptually correct to divide the code needed at runtime from
   the one necessary to actually compile.

3- at the first startup on my configuration only gv.el gets native
   compiled!

Limitations so far are that:

1- if any of the async compilation will have to report a warning,
   warnings.el will require icons.el that will still require cl-lib.el.

2- if cl-lib.el and other dependencies of the native-compiler are not
   native compiled because of some other package gets loaded, they might
   stay bytecode.  In this case the native compilers running in
   background _might_ have some performance degradation.  I guess is
   more theoretical than practical but we might want to have a look
   before committing.

Bests!

  Andrea



reply via email to

[Prev in Thread] Current Thread [Next in Thread]