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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Mon, 15 Dec 2014 17:36:01 UTC

Severity: normal

Found in version 25.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

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
Subject: bug#19390: 25.0.50; `package-activate' is too slow
Date: Tue, 16 Dec 2014 19:35:38 -0200
2014-12-16 12:31 GMT-02:00 Dmitry Gutov > On 12/16/2014, Artur Malabarba wrote:
>
>> I didn't notice anything as aggravating as the report, but I agree my
>> latest patch is a performance concern.
>
> Do you maybe have fewer packages installed?

Perhaps.
But the reason is beyond the point, :-) I agree this patch needs
performance improvements.

> Any particular reason you're using file-truename', instead of
&gt;expand-file-name'? Replacing the former with the latter already gives
> ~twofold performance improvement.

Yes, I originally used `expand-file-name', but
`package--list-loaded-files' would miss some files if there was a
symlink in the path. (I specifically observed this, it's not just
theory).
The problem is that a file returned by `find-libary' could be the same
as another file contained in  `load-history' but have a different name
(because of symlinks).


>> 2. Creating the `history' variable as below is a problem.
>>
>> (mapcar (lambda (x) (file-name-sans-extension
>>                                    (file-truename (car x))))
>>                      load-history)
>
>
> With the above change, this piece of code is relatively fast.
>
> For instance, (package--list-loaded-files default-directory) in the Helm
> directory takes 140 ms here, whereas
>
>             (mapcar (lambda (x) (file-name-sans-extension
>                                  (expand-file-name (car x))))
>              load-history)
>
> only takes ~10 ms. Still not fast enough not to need the other patch, of
> course.

Yes, I agree `file-truename' is slow. The foolproof way would be to
have a variable that stores the `file-truename's, so we wouldn't have
to calculate them.
Using `expand-file-name' is a valid way to improve performance here,
but it won't *always* reload the files for all users.




This bug report was last modified 10 years and 236 days ago.

Previous Next


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