[core] Minor enhance for performance

[sunlin7]

Minor performance enhance with substr, in my local, it's reduce the startup time from ~0.95s to ~0.88s

403 packages loaded in 0.887s (elpa 309, recipe 27, local 4, built-in 63)

[bcc32]

I'm somewhat opposed to this. I don't think the speedup is worth the extra difficulty in debugging something as critical as file loading (see the info page on defsubst).

Perhaps you could instead use a different data structure like a hash table and get a speedup that way?

[sunlin7]

Current list structure is the balance choice for maintenance and performance.
The scenario is multiple filenames mapping to one folder, for example, searching any fileA0/1/2 will get the folder ...pkg-X as the result:

fileA0 ---\
fileA1 ---->   ~/.emacs.d/elpa/pkg-X/
fileA2 ---/

A hash or radix-tree structure will has performance benefits on searching but it introduce the deleting pains. For example, using a hash to map file -> directory; when package directory was deleted (inside or outside), then Emacs want remove the file entries, it have to scan file->dir hash table to find the file items which folder does not exists, it would be expensive (There're 309 packages, 1829 *.el files in my local).

This minor change has no risk but will get performance benefit.
Please consider approve it. Thank you!

[smile13241324]

I think thats cool to be honest. We can cope with the extra complexity if it makes Spacemacs better. Being faster at startup is still something where we could get better. So lets merge it and see if we really run into issues with this.

Modern emacs packages do rely on native code and will do so more and more in time. I think we should embrace the move rather than try to stay behind.

[bcc32]

Modern emacs packages do rely on native code

This isn't a native code issue. defsubst prevents the function it defines from being redefined, profiled, or advised, and doesn't work with debug-on-entry either.

From the Elisp manual:

Also, inline functions do not behave well with respect to debugging,
tracing, and advising (*note Advising Functions::). Since ease of
debugging and the flexibility of redefining functions are important
features of Emacs, you should not make a function inline, even if it’s
small, unless its speed is really crucial, and you’ve timed the code to
verify that using ‘defun’ actually has performance problems.

IMO this speedup may not be worth it, but of course that is just my opinion.

FWIW I will not be fighting to have this change reverted (in my site's fork, we have already excluded the load-hints patch). But, I think future caution is warranted around defsubst.

[sunlin7]

Thanks for the detailed information to help me better understand the risk and limitation. I searched the Spacemacs code base, only few functions defined by the defsubst, we do need carefully using the defsubst, I agree with you.

This change won't affect normal Spacemacs users; only affect the user who want extreme startup speed, that show off how fast Spacemacs can be.

Thank you all of you.