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: Thu, 18 Dec 2014 13:15:16 -0200 Message-ID: References: <86a92oddfp.fsf@yandex.ru> <86mw6nkc6n.fsf@yandex.ru> <54904241.8010000@yandex.ru> <5490BFCD.5050505@yandex.ru> <5490ED6D.5080808@yandex.ru> <868ui5ervl.fsf@yandex.ru> <5492AE61.3040902@yandex.ru> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0149c1ce491dc2050a7f0f7a X-Trace: ger.gmane.org 1418915791 24771 80.91.229.3 (18 Dec 2014 15:16:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 15:16:31 +0000 (UTC) Cc: 19390@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 18 16:16:19 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 1Y1coK-00062E-Dr for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Dec 2014 16:16:16 +0100 Original-Received: from localhost ([::1]:54364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1coJ-00070d-Oz for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Dec 2014 10:16:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1coB-0006vt-SP for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 10:16:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1co6-0002k3-Or for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 10:16:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:40849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1co6-0002jz-KU for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 10:16:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y1co6-0001Sc-BP for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 10:16: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: Thu, 18 Dec 2014 15:16: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.14189157215556 (code B ref 19390); Thu, 18 Dec 2014 15:16:02 +0000 Original-Received: (at 19390) by debbugs.gnu.org; 18 Dec 2014 15:15:21 +0000 Original-Received: from localhost ([127.0.0.1]:50215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1cnQ-0001RX-QA for submit@debbugs.gnu.org; Thu, 18 Dec 2014 10:15:21 -0500 Original-Received: from mail-oi0-f41.google.com ([209.85.218.41]:63725) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1cnN-0001RO-ID for 19390@debbugs.gnu.org; Thu, 18 Dec 2014 10:15:18 -0500 Original-Received: by mail-oi0-f41.google.com with SMTP id a3so505949oib.14 for <19390@debbugs.gnu.org>; Thu, 18 Dec 2014 07:15:17 -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=nnfkAJlrtvnXc1l6nYLXSvbjVYcN5uQoRqyvwzr6IWo=; b=kbFavIwrc4NGeQ7kpTgHchZtRhSi1xgPk13AO/SIFiTq6Si7vpCuLLAbAHwjLS4pIP NI+Fty+DSas4NT3gYOyrCfFARAF6plvIPvks9nyr648tdfAUU3uZCDhcTBT+QTp6WsZF BT3nvsyErEki9emhTNSSPxr0/75eFuHtJDXIVpJNoJQ7BKGlbT5L2hLY1XF/5waGS2rR 2z96XSl8/xz51KMHaSiNhjFIy4V+sni5wRtGiWZrkxnbrpD5AWJ5wWuogtI/hoepDjDa cN33EcMpwRMFvlt6RDLOSAzGBfmztXTFz1m0qUAlzWWOnZW7hZDZnAhckZODmJClpjwZ nqog== X-Received: by 10.182.102.161 with SMTP id fp1mr1616311obb.29.1418915717125; Thu, 18 Dec 2014 07:15:17 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Thu, 18 Dec 2014 07:15:16 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Thu, 18 Dec 2014 07:15:16 -0800 (PST) In-Reply-To: <5492AE61.3040902@yandex.ru> X-Google-Sender-Auth: ipMwuGCsdaot2rYnaplaRrpCAPs 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:97507 Archived-At: --089e0149c1ce491dc2050a7f0f7a Content-Type: text/plain; charset=UTF-8 On 18 Dec 2014 08:37, "Dmitry Gutov" wrote: > > On 12/18/2014 04:11 AM, Artur Malabarba wrote: > >> I agree. And no, IIUC this hasn't been implemented yet. I suggested a >> couple of style improvements and haven't heard back. > > > Sorry, got sidetracked. Installed with suggestions, except for the last docstring line (too obvious IMO). Awesome :-) > Still, I think we'd rather not spend too much time on reloading packages when upgrading, so please consider my latest patch. 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). 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. > Aside from it, if we compare with the alternative implementation suggestions, the current one reloads all dependencies, even those that haven't been (re)installed during the current session. Is that so? Reading your patch, and from what I understand of the current implementation, they only reload packages on installation. So they shouldn't reload dependencies that weren't upgraded. --089e0149c1ce491dc2050a7f0f7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 18 Dec 2014 08:37, "Dmitry Gutov" <dgutov@yandex.ru> wrote:
>
> On 12/18/2014 04:11 AM, Artur Malabarba wrote:
>
>> I agree. And no, IIUC this hasn't been implemented yet. I sugg= ested a
>> couple of style improvements and haven't heard back.
>
>
> Sorry, got sidetracked. Installed with suggestions, except for the las= t docstring line (too obvious IMO).

Awesome :-)

> Still, I think we'd rather not spend too much time = on reloading packages when upgrading, so please consider my latest patch.

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 fi= le that has the same name as a feature (we require files in the load path t= o be uniquely named, but load-history contains all files, not just those in= the load path).

It's an edge case, and my opinion is that a good perform= ance improvement is more important than that. But it seems like the 2 bigge= st performance improvements have already been made (the package initialize,= and the file true name), so I wonder if it's worth it.

> Aside from it, if we compare with the alternative imple= mentation suggestions, the current one reloads all dependencies, even those= that haven't been (re)installed during the current session.

Is that so? Reading your patch, and from what I understand o= f the current implementation, they only reload packages on installation. So= they shouldn't reload dependencies that weren't upgraded.

--089e0149c1ce491dc2050a7f0f7a--