Async rebuild package-quickstart after packages update? was Re: 28.0.50; Proposal: slightly more efficient package-quickstart.el

[T.V Raman]

One place where we could gain perceptible speedup is when
package-quickstart is rebuilt after updating packages; could we make
that function asyn?
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.
>
>> 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.
>
> Still, that presumes that finding a file is the main issue, but I don't
> know if that would indeed be true.
>
>> (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))))
>           ...)))
>
>
> -- Stefan
>
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
?7?4 Id: kg:/m/0285kf1  ?0?8