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

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Not so much, but it is not so much about noticable difference, more
>>>> about not performing unnecessary computation.
>> I agree that simplicity and code clarity is important, on many
>> levels. But maybe we can have the cake and it it too, as you said 
>> for wdired?
>
> In the case of wdired there was a concrete gain.
> Here it's only hypothetical, so the positive motivation is quite different.
> Also `package-quickstart` is fairly tricky to troubleshoot (beyond removing
> or refreshing the file).  To the end user it's largely a magical button,
> so it's really important to make it work reliably.
>
> IOW the incentives are strongly opposed to your proposition.
For me the positive motivation here is to not do unnecessary
calculations, not so much the speed gain. I don't understand why speed
is the only measurement of improvement. Even replacing 'add-to-list' with
a 'push' to load-path would be an improvemnt, but the patch would be not
much different. Anyway, if there is no incentive to change this so it is
:).

>> Last weekend I tested actually myself to restructure how my packages are
>> loaded. I noticed that init time increased after I added ~100 packages,
>> just for test, and I didn't required anything of that into Emacs. So I
>> tested the idea to put all .elc file into a single place and skipp in
>> entirety this monstrosity of load-path that results after 200 packages
>> are loaded. I got it to work to a degree, it least I got running Emacs,
>> native compiler not complaining and most packages loaded, but I also got
>> some cyclic dependency, notably for dired and semantic of all things,
>> that actually rendered entire session unusable for the most part. I'll
>> leave that for another day when I have some more time.
>
> Moving the .elc files to a separate (short) list of directories indeed
> one way we could address the situation where there are too many entries
> on `load-path`.
>
> Another way would be to scan `load-path` "once" and populate
> a hash-table from that, after which (load "foo" ...) could be sped up by
> looking up "foo" in the hash-table.

Sure either could work, hash table would probably be faster since it
would effectively be a database in memory, but it also means it will
cost more in RAM and also be even more complicated since you will have
to modify how require works. Copying over .elc files in some kind of
"package-cache" after the package installation is done is probably
less change.

> Still, that presumes that finding a file is the main issue, but I don't
> know if that would indeed be true.

For me the main issue here was to skip needless work :). I think the
things wouold be speedier, but I don't know how much of that would be
percieved by the end user. Requiring features is not very frequent
issue, and most of it is done anyway at some well defined points like
emacs starting up, or loading a mode or something similar.

>> (when (re-search-forward rx-path-beg nil t)
>>             (goto-char (line-beginning-position))
>>             (setq temp-point (point))
>>             (forward-sexp)
>>             (when (search-backward file nil t 1)
>>               (goto-char temp-point)
>>               (kill-sexp)))
>
> I'd do something like
>
>     (while (re-search-forward "^(add-to-list" nil t)
>       (goto-char (match-beginning 0))
>         (let ((start (point))
>               (x (read (current-buffer))))
>           ...)))
>
Ok, thank you. I haven't used 'read' yet so I wasn't thinking in that
direction.