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 15:39:30 -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> <5492F68C.3090700@yandex.ru> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c21ca8177629050a8113f5 X-Trace: ger.gmane.org 1418924431 14580 80.91.229.3 (18 Dec 2014 17:40:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 17:40: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 18:40:22 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 1Y1f3h-0004C8-KQ for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Dec 2014 18:40:17 +0100 Original-Received: from localhost ([::1]:55116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1f3h-0004eO-2q for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Dec 2014 12:40:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1f3a-0004eG-2R for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 12:40:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1f3U-0001U0-Vh for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 12:40:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1f3U-0001SM-Rm for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 12:40:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y1f3T-0005QH-9d for bug-gnu-emacs@gnu.org; Thu, 18 Dec 2014 12:40:03 -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 17:40: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.141892437620789 (code B ref 19390); Thu, 18 Dec 2014 17:40:02 +0000 Original-Received: (at 19390) by debbugs.gnu.org; 18 Dec 2014 17:39:36 +0000 Original-Received: from localhost ([127.0.0.1]:50443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1f31-0005PE-21 for submit@debbugs.gnu.org; Thu, 18 Dec 2014 12:39:35 -0500 Original-Received: from mail-oi0-f49.google.com ([209.85.218.49]:37385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y1f2x-0005P4-LY for 19390@debbugs.gnu.org; Thu, 18 Dec 2014 12:39:32 -0500 Original-Received: by mail-oi0-f49.google.com with SMTP id i138so692878oig.8 for <19390@debbugs.gnu.org>; Thu, 18 Dec 2014 09:39:31 -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=AoEJYmiPlEvuvyluEQm+4NAXYUeumVtxWpwAH43lQEY=; b=wOhaqcrRLkiA9Rwaitzle9BhUJ89TflqVmHamFOZKsOq5TlmY2BoI972aYZ/sx1hK4 eYZ+qaIE7ixhxbewetEOgUPqFOHMHpxQnZ9u1KtfPXsXQCWgFXzV3iDo/k+7/z8Sng8v gVKsiFy1FvmsxH0pOhSGDSuwOw/UXwK9fLtU0eOGmJXirjQqOJdRwYGNIUvOHKJoCRN3 gHT9sDM5olS9M4qQ65mmV+XtQGi6r2UouYJW8AHXi6ABN0SOoNOe3yheO0WfXXmMHT89 vkyukE7Ooxz+EXkq7QFjm8YNvdjmwFDO7KEYw1dJoZXXuDXsVH2UmBMENj8uNVKWcVel u8hQ== X-Received: by 10.60.62.241 with SMTP id b17mr1070308oes.17.1418924370914; Thu, 18 Dec 2014 09:39:30 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Thu, 18 Dec 2014 09:39:30 -0800 (PST) Original-Received: by 10.76.26.162 with HTTP; Thu, 18 Dec 2014 09:39:30 -0800 (PST) In-Reply-To: <5492F68C.3090700@yandex.ru> X-Google-Sender-Auth: ImDHtSFKKsUWpUVmZpv_sD_vNpE 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:97532 Archived-At: --001a11c21ca8177629050a8113f5 Content-Type: text/plain; charset=UTF-8 On 18 Dec 2014 13:45, "Dmitry Gutov" 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 --001a11c21ca8177629050a8113f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 18 Dec 2014 13:45, "Dmitry Gutov" <dgutov@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, no= t 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 goo= d performance improvement
>> is more important than that. But it seems like the 2 biggest perfo= rmance
>> improvements have already been made (the package initialize, and t= he
>> file true name), so I wonder if it's worth it.
>
>
> 200ms per package initialization still seems a lot to me (even if it&#= 39;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 th= is percentage should be small. But

--001a11c21ca8177629050a8113f5--