Re: 28.0.50; Proposal: slightly more efficient package-quickstart.el

[Stefan Monnier]

Arthur Miller [2021-07-20 02:27:26] wrote:
> Since quickstart file is created by iterating through each and one
> installed package whose path is already known, this calculation can be
> performed once at generation time, rather than every time when Emacs
> starts.

It's indeed an optimization we can perform.  I'm not sure it's worth the
extra code, tho, since there's always a risk it will break something.

Have you made some measurements to see if it the difference is noticeable?

> -        (Info-directory-list '("")))
> +        (Info-directory-list '(""))
> +        paths)

The GNU coding standard would call this `dirs` since a "path" is a list
of directories used for searching.  I guess you could also call it
`path` (singular).

> @@ -4164,6 +4166,10 @@
>                (replace-match (if (match-end 1) "" pfile) t t)))
>            (unless (bolp) (insert "\n"))
>            (insert ")\n")))
> +      (goto-char (point-min))
> +      (while (re-search-forward "^(add-to-list.*load-path" nil t)
> +        (goto-char (line-beginning-position))
> +        (kill-sexp))
>        (pp `(setq package-activated-list
>                   (append ',(mapcar #'package-desc-name 
> package--quickstart-pkgs)
>                           package-activated-list))

Beside the hypothetical risk that the regexp matches an `add-to-list` to
an unrelated variable, I think this risks introducing real bugs for
packages which use (add-to-list 'load-path <subdir>) to add
*sub*directories.

> @@ -4175,6 +4181,10 @@
>                        (setq Info-directory-list
>                              (append ',info-dirs Info-directory-list)))
>                (current-buffer))))
> +      (goto-char (point-min))
> +      (forward-line 3)
> +      (insert (concat "\n(nconc load-path '" (prin1-to-string paths) ")\n"))
> +      (goto-char (point-max))

This inserts the dirs at the end of `load-path` whereas `add-to-list`
usually adds them to the beginning.  I think this will break configs
where a newer version of Org is installed (because the built-in Org
will then take priority).

Of course, we can fix those problems, but unless there's a compelling
performance argument, I think it's a waste of time.


        Stefan