Re: feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> I'd rather have the "lots of directories" setup, if I had to choose.
>> It's significantly better in the long term IMHO, so it's worth
>> short-term inconvenience and acclimation.
>
> If we take the files bundled with Emacs and look at how many ELPA
> packages they would turn into, we'd end up with a load path that has
> more than 200 elements.

My load-path has 151 at the moment. Although a lot of these appear to be
duplicates for some reason.


> FWIW, I've always been wary of having "one dir per package" because of
> the performance impact of having a thousand directories in load-path.
> Lookup in a large directory is easily optimized to O(log N) or something
> like that, but a search along load-path won't be similarly optimized by
> the kernel.
>
> [ In `install.el` (an old package that predates package.el), I installed
>   all single-file packages into a shared directory specifically for
>   that reason.  ]
> This is not based on actual experience, tho, so maybe I'm worrying about
> nothing.

I think it's a valid concern, although as with all of these things, it's
hard to tell without building it and trying it. I guess you would mostly
be worried about start up?

Of course, with a few heuristics, it would be possible to speed this up.
For example, if we had a "one package per directory" layout, we could
have `load` look for `blah.el` or `blah-subpackage.el` in the "blah"
directory first. If package.el stored the current version of each
package, somewhere, you could make this lookup pretty close to constant
time.

Phil