GNU bug report logs - #19390
25.0.50; `package-activate' is too slow

Previous Next

Full log

View this message in rfc822 format

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19390 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#19390: 25.0.50; `package-activate' is too slow
Date: Thu, 18 Dec 2014 15:39:30 -0200

[Message part 1 (text/plain, inline)]

On 18 Dec 2014 13:45, "Dmitry Gutov" <dgutov <at> yandex.ru> 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.