bug#41646: Startup in Windows is very slow when load-path contains many

[Eli Zaretskii <eliz@gnu.org>]

> From: Lin Sun <sunlin7.mail@gmail.com>
> Date: Fri, 1 Nov 2024 17:58:01 +0000
> Cc: monnier@iro.umontreal.ca, stefankangas@gmail.com, acorallo@gnu.org, 
> 	41646@debbugs.gnu.org, monnier@gnu.org
> 
> > > > How will the '"file1" "file2" ...' part be created?
> > >
> > > For the Emacs built in paths, we can create the (<path> [files])
> > > during bootstrap and write to the "subdirs.el", then it will push the
> > > extended (<path>, files...) into `load-path'.
> >
> > I don't understand: isn't this supposed to speed up primarily users
> > who have many 3rd-party packages installed?  For them, what happens
> > during bootstrap is not relevant.
> >
> > If all we want is to record the places where bundled files live,
> > that's a much easier problem.
> Sorry for the fuzz "bootstrap", the "bootstrap" I wanted to say is
> part of building steps, like "make bootstrap", then we can build the
> files list into the "subdir.el".

I still don't understand: below you are talking about installing 300+
packages using package.el, so "make bootstrap" is not relevant.

> Both the startup time and running time will be affected by too many
> "load-path" entries.
> Like the "package.el", it will add all 300+ packages' paths on the top
> of "load-path" at the beginning of startup, the builtin paths will be
> on the bottom of "load-path", after that a simple "(require
> '<builtin-feature>)" will trigger emacs to walk through the
> "load-path" from top to bottom, that leads thouthands
> open-attemptions, that happened during emacs startup, or during
> running time.

So now we are talking not only about startup, but also about what
happens after that?

It is hard to discuss a feature whose goal and the problems it
attempts to solve shift around all the time.  Can we please formulate
the goals and not change them afterwards?