[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 14:27:02 +0300 |
> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, Gregory Heytings <gregory@heytings.org>,
> rms@gnu.org, emacs-devel@gnu.org
> Date: Tue, 24 Oct 2023 11:10:06 +0300
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Preloading unnecessary stuff is a slippery slope that once we start
> >> there's no way of knowing where we end. So let's not.
> >
> > AFAIK, the main drawback is increased memory consumption. The main
> > benefit is that Emacs starts faster.
>
> About how much memory are we talking here? All this sounds like talk
> about micro optimizations.
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.
The only way of keeping this kind of bloat at bay is to resist adding
anything, no matter how small, because, like I said, it's a slippery
slope.
> 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.
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Corwin Brust, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Corwin Brust, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Stefan Kangas, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Björn Bidar, 2023/10/24
- 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/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Björn Bidar, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/27
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/23