Re: cl-lib warnings

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Juanma Barranquero <lekktu@gmail.com>, João Távora
>  <joaotavora@gmail.com>,  juri@linkov.net,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Thu, 05 Jan 2023 22:40:24 -0700
> 
> >> Our policy and practice was since long ago that any package which is
> >> always or almost always loaded at startup without any user say-so,
> >> should be preloaded, since not doing that makes very little sense.
> >   
> > We don't have precise metrics for "always or almost always loaded at startup",
> > I think.
> >
> > But cl-lib is unconditionally required by 191 files under lisp/, right
> > now.  Including things like desktop, help-fns, help-mode, kmacro,
> > imenu, tab-line and package, among many others.  And of course vc,
> > Calc and Org. And use-package, which will perhaps become the de facto
> > way to customize their .emacs for many people.
> 
> Eli's the only person who's expressed concern about preloading cl-lib,
> but I don't believe he's responded to Juanma's statistics here.
> 
> Eli, what do you think about this argument that cl-lib meets the
> criteria you stated?

It doesn't.  If you think it does, I must have failed to explain the
criteria.

The "almost always" is not a numerical criterion, its "almost" part is
intended to cover the cases where the package is _always_ loaded at
startup, but only in some configurations of Emacs.  Like something
that happens only in GTK builds.  So counting the number of Lisp
packages that require cl-lib is not going to change my mind.

In general, I'm worried by IMO too nonchalant attitude towards
preloading more and more into Emacs.  We should actively try to keep
the memory footprint of the Emacs process in check.  It is true that
each package we add increases the footprint by a small amount, but
those small amounts eventually add up to a sum that is significant.
On my system starting "emacs -q" with various versions of Emacs
produces the following memory footprint values:

  emacs 22.1  10.6 MiB
  emacs 23.1  11.5 MiB
  emacs 24.1  13.4 MiB
  emacs 25.1  32.5 MiB
  emacs 26.1  35.5 MiB
  emacs 27.1  25.1 MiB
  emacs 28.2  26.7 MiB

Granted, not all of the increase is due to preloading more Lisp, but
some of it is, and so IMO we should resist the temptation to add more
just because it saves us some 'require's.