[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lisp files that load cl-lib in problematical ways
From: |
Eli Zaretskii |
Subject: |
Re: Lisp files that load cl-lib in problematical ways |
Date: |
Thu, 26 Oct 2023 08:16:52 +0300 |
> From: Andrea Corallo <acorallo@gnu.org>
> Cc: stephen.berman@gmx.net, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Wed, 25 Oct 2023 18:02:52 -0400
>
> 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!
Sounds good to me, thanks.
> 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.
I don't see this as a significant problem. Here's my data point: I
use desktop.el to save/restore my production sessions, which tend to
be large, so when a new version of Emacs starts, I have more than 200
packages natively-compiled in the background during the first 2
minutes, and not a single warning emitted. Granted, those are all
bundled packages, but why shouldn't we expect third-party packages to
live up to the same standards?
And in addition, users can always turn off the warnings if loading
cl-lib bothers them.
> 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.
Doesn't happen here: I see that cl-lib is natively-compiled in the
very first group of files compiled after Emacs starts.
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Stephen Berman, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways,
Eli Zaretskii <=
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Alan Mackenzie, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19