From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#19390: 25.0.50; `package-activate' is too slow Date: Fri, 19 Dec 2014 10:08:08 -0200 Message-ID: References: <86a92oddfp.fsf@yandex.ru> <5490BFCD.5050505@yandex.ru> <5490ED6D.5080808@yandex.ru> <868ui5ervl.fsf@yandex.ru> <5492AE61.3040902@yandex.ru> <868ui5aubr.fsf@yandex.ru> <5492FDBD.1040704@yandex.ru> <549314D7.8070106@yandex.ru> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2b12cdd72fc050a908ffe X-Trace: ger.gmane.org 1418990967 24311 80.91.229.3 (19 Dec 2014 12:09:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Dec 2014 12:09:27 +0000 (UTC) Cc: 19390@debbugs.gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 19 13:09:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y1wMu-0003Qy-78 for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Dec 2014 13:09:16 +0100 Original-Received: from localhost ([::1]:58044 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1wMt-0002yb-HM for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Dec 2014 07:09:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1wMl-0002uO-B9 for bug-gnu-emacs@gnu.org; Fri, 19 Dec 2014 07:09:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1wMg-000660-HE for bug-gnu-emacs@gnu.org; Fri, 19 Dec 2014 07:09:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1wMg-00065u-EB for bug-gnu-emacs@gnu.org; Fri, 19 Dec 2014 07:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y1wMg-0004qS-3B for bug-gnu-emacs@gnu.org; Fri, 19 Dec 2014 07:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Dec 2014 12:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19390 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19390-submit@debbugs.gnu.org id=B19390.141899089118553 (code B ref 19390); Fri, 19 Dec 2014 12:09:02 +0000 Original-Received: (at 19390) by debbugs.gnu.org; 19 Dec 2014 12:08:11 +0000 Original-Received: from localhost ([127.0.0.1]:50872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1wLq-0004pB-TF for submit@debbugs.gnu.org; Fri, 19 Dec 2014 07:08:11 -0500 Original-Received: from mail-oi0-f46.google.com ([209.85.218.46]:56375) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1wLp-0004oz-77 for 19390@debbugs.gnu.org; Fri, 19 Dec 2014 07:08:09 -0500 Original-Received: by mail-oi0-f46.google.com with SMTP id h136so1322762oig.5 for <19390@debbugs.gnu.org>; Fri, 19 Dec 2014 04:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aQB0HQqA6Xew7bX6PlQeuSatO6V2EBzuEw0mjQ4WEG4=; b=JfaOjUkBmO1YIQhZYEeEBQ1fSem63lT+eUsdZYKO34DJUtJl7CbKeSAj+K4WV0ZLDN JcOvBwHISw1b5LbaXPIjuNVg6CTAgC2KDOTLFXWUOUgwpKJya0jpiCNTiOSCajttWDGj oNyQpHZDb+myXYdM9jOJk7BlsooH84qeHNLTWqIJxW1eNQp3NMFJRCNnoN4PbqV7hIFo Frqhb2AZ0VFzMp5lKztBbo3YTe/uzoIQUon2YWt66J6xDfvPN4Y+5W62DoJ2vuGP4Siu 9SxhU6ez8sAp+Ay+oaK9y+dGfaHZSSzczmgmy+7FfTfaFoBqewcvRSAoWoVM5DNNTE4i 1GOg== X-Received: by 10.182.210.232 with SMTP id mx8mr4577049obc.46.1418990888774; Fri, 19 Dec 2014 04:08:08 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Fri, 19 Dec 2014 04:08:08 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Fri, 19 Dec 2014 04:08:08 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: E1KibqRu3ibwZVGkNNI19E7oA3s X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:97566 Archived-At: --001a11c2b12cdd72fc050a908ffe Content-Type: text/plain; charset=UTF-8 On 19 Dec 2014 02:31, "Stefan Monnier" 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. --001a11c2b12cdd72fc050a908ffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 19 Dec 2014 02:31, "Stefan Monnier" <monnier@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 c= an be
> called repeatedly, on the assumption that in most cases, this `require= '
> will be "instantaneous".=C2=A0 I'd rather not re-conside= r this
> performance choice.
>
> I'm OK with slowing down require like you suggested (that was actu= ally
> my original suggestion to handle the byte-compilation breakage during<= br> > package upgrade), but then we'd only want to do it in some specifi= c
> contexts (during byte-compilation) rather than all the time.
>
> > When `autoload' is called, if the function in question is com= pletely
> > defined (instead of not defined or just autoloaded), `autoload= 9; will
> > check if the file it was given is a different file from the one t= he
> > 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= 9;s too late now to be slowing down `require'. If there's code in E= macs core that relies on its speed, God knows how much code like that is fl= oating around on the other Elpas or the wiki.

Better stick with the version we have now.

--001a11c2b12cdd72fc050a908ffe--