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

Previous Next

Full log

Message #148 received at 19390 <at> debbugs.gnu.org (full text, mbox):

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

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

On 19 Dec 2014 02:31, "Stefan Monnier" <monnier <at> iro.umontreal.ca> wrote:
>
> > `require' is only ever called as part of loading package (or doing
> > some other processing).
>
> There are a few places where we `require' inside a function that can be
> called repeatedly, on the assumption that in most cases, this `require'
> will be "instantaneous".  I'd rather not re-consider this
> performance choice.
>
> I'm OK with slowing down require like you suggested (that was actually
> my original suggestion to handle the byte-compilation breakage during
> package upgrade), but then we'd only want to do it in some specific
> contexts (during byte-compilation) rather than all the time.
>
> > When `autoload' is called, if the function in question is completely
> > defined (instead of not defined or just autoloaded), `autoload' will
> > check if the file it was given is a different file from the one the
> > function was defined in (when we know that file).
> > If it is then all is fine, if it wasn't then it loads the new file.
>
> So we first add handling for `require', then another for `autoload',
> ... in the end I can't believe it can be simpler than what we have
> (which has 0 cost in normal use, and a very small extra cost during
> package upgrade).

In terms of lines of code, I think it would end up simpler, despite having
to patch 3 functions instead of 1. Still, I understand it's too late now to
be slowing down `require'. If there's code in Emacs core that relies on its
speed, God knows how much code like that is floating around on the other
Elpas or the wiki.

Better stick with the version we have now.

[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.