Open aaronjensen opened 1 week ago
Feature Description
Hi, do you have any plans for a
package-quickstart
equivalent and/or have you tested whether or not it offers much performance benefit on a modern machine?Confirmation
- [X] The feature I'm proposing does not already exist in Elpaca
Thanks for the suggestion.
Currently, if elpaca-cache-autoloads
is non-nil (the default), all of a package's autoloads are read into memory and an entire queue's worth are evaluated at once. This is all done utilizing a single buffer, too.
At one point I experimented with concatenating autoloads during package building, but I have not done rigorous enough testing to say whether or not it's worth it. Another similar optimization would be adding the minimum set of directories to load-path
, which would optimize elisp library look up time. Both ideas can be accomplished by writing custom build steps, but I haven't done so. As a feature, I think it's fairly low priority right now.
If you're interested and need help writing the custom build steps, I can give advice.
Another similar optimization would be adding the minimum set of directories to load-path, which would optimize elisp library look up time
What would the minimum set entail? I'm not sure I understand this one.
As for the custom build step, are you imagining that after building each package it would append its autoloads to a single file? Or is there a post-build-of-everything step that could be used to more or less enumerate all packages and concatenate their autoloads?
Another similar optimization would be adding the minimum set of directories to load-path, which would optimize elisp library look up time
What would the minimum set entail? I'm not sure I understand this one.
Any libraries which can operate with a set of uniquely named files can co-exist in the same directory on load-path
. e.g. elisp/a.el
, elisp/b.el
. The only case you'd need more directories is when libraries depend on files which are not uniquely named. I haven't experimented enough with this to see whether it's worth the effort.
As for the custom build step, are you imagining that after building each package it would append its autoloads to a single file?
Correct.
As for the custom build step, are you imagining that after building each package it would append its autoloads to a single file?
Correct.
Hmm, it would need to be rebuilt from scratch any time the packages changed (i.e., one was added or removed). That's probably more complexity than I can take on, but maybe I can experiment with whether or not the performance difference is notable on modern machines.
Feature Description
Hi, do you have any plans for a
package-quickstart
equivalent and/or have you tested whether or not it offers much performance benefit on a modern machine?Confirmation