progfolio / elpaca

An elisp package manager
GNU General Public License v3.0
659 stars 32 forks source link

[Feature]: Merging autoloads? #388

Open aaronjensen opened 1 week ago

aaronjensen commented 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

progfolio commented 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.

aaronjensen commented 1 week ago

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?

progfolio commented 6 days ago

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.

aaronjensen commented 6 days ago

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.