|Subject:||bug#19390: 25.0.50; `package-activate' is too slow|
|Date:||Thu, 18 Dec 2014 15:39:30 -0200|
On 18 Dec 2014 13:45, "Dmitry Gutov" <address@hidden> wrote:
> On 12/18/2014 05:15 PM, Artur Malabarba wrote:
>> There's a bit of a small flaw with that approach, it's the reason I used
>> If you just check load files against their names, you could find a wrong
>> file that has the same name as a feature (we require files in the load
>> path to be uniquely named, but load-history contains all files, not just
>> those in the load path).
> Like mentioned, we can also check against the `provide' values in each load-history element we find matching. Shouldn't be a perceptible performance hit.
If it's trivial to do, that's certainly good.
>> It's an edge case, and my opinion is that a good performance improvement
>> is more important than that. But it seems like the 2 biggest performance
>> improvements have already been made (the package initialize, and the
>> file true name), so I wonder if it's worth it.
> 200ms per package initialization still seems a lot to me (even if it's only for certain packages). I also happen to think that the suggested code is a bit easier to understand, but it's up to you.
During package-initialize these things add up, so that's certainly a lot. But during a regular upgrade, what fraction of the total load time does that amount to? Even for large packages like helm I think this percentage should be small. But
|[Prev in Thread]||Current Thread||[Next in Thread]|