[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Phillip Lord
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Wed, 19 Oct 2016 20:57:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]