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: Eli Zaretskii
Subject: Re: Lisp files that load cl-lib in problematical ways
Date: Tue, 24 Oct 2023 18:54:42 +0300

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: stefankangas@gmail.com,  gregory@heytings.org,  rms@gnu.org,
>   emacs-devel@gnu.org
> Date: Tue, 24 Oct 2023 18:29:55 +0300
> 
> > If we ignore such "micro optimizations", we will quickly bloat Emacs,
> > since those small amounts add up.  We have a lot of relatively small
> > potential additions that we make a point of not adding, because if we
> > decide adding one is okay, then why not add all the rest?  We don't
> > add such stuff to subr.el or to simple.el or to files.el, and keep
> > them separate, precisely because adding them all will not be
> > insignificant.
> 
> I get that point but in this case we talk about doing something
> slightly different to not load cl-lib while eventually cl-lib is loaded
> anyway.

How is cl-lib different from any other package that is extremely
likely to be loaded close to a beginning of a production session?

The rationale for not loading anything we don't strictly need is that
different users have different use patterns, and Emacs can be used in
different modes: a GUI or TTY interactive session (with various user
customizations that load packages), a batch command, in a script using
--script, as a daemon, etc.  Each one of these needs different
optional modes needs to load different packages; preloading things
that are frequently loaded is therefore likely to load stuff needed by
some other mode/configuration, and that is simply not clean, besides
the fact that it "punishes" users by having them load stuff they don't
need.  E.g., my production session loads no less than 214 packages
right when it starts.  Why would we do that when everything works
without it?  What kind of problem are we trying to solve here?  I see
no problem.

> >> Emacs speed is more limited about it being single threaded most of the
> >>  time than anything else.
> >
> > I don't see the relevance, sorry.  We can work on making Emacs faster
> > without bloating it.
> 
> >From my pov Emacs start up time or speed is more limted by Emacs being
> single threaded rather than loading a few kbs of code that will be
> loaded later anyway.

So our POVs differ.  Lat's agree to disagree about that.



reply via email to

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