[Top][All Lists]

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

bug#19390: 25.0.50; `package-activate' is too slow

From: Artur Malabarba
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
>> find-library.
>> 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

reply via email to

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