From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Newsgroups: gmane.emacs.bugs Subject: bug#41646: Startup in Windows is very slow when load-path contains many entries. Date: Mon, 1 Jun 2020 11:26:35 -0300 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="80269"; mail-complaints-to="usenet@ciao.gmane.io" To: 41646@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 01 16:27:16 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jflPI-000Kmr-GY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Jun 2020 16:27:16 +0200 Original-Received: from localhost ([::1]:40314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jflPH-0001cG-HT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Jun 2020 10:27:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jflP4-0001ax-U8 for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2020 10:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jflP4-0002I4-LU for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2020 10:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jflP4-0006UX-H1 for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2020 10:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jun 2020 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 41646 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.159102161124934 (code B ref -1); Mon, 01 Jun 2020 14:27:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 1 Jun 2020 14:26:51 +0000 Original-Received: from localhost ([127.0.0.1]:36684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jflOt-0006U6-11 for submit@debbugs.gnu.org; Mon, 01 Jun 2020 10:26:51 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:42044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jflOq-0006Ty-Pr for submit@debbugs.gnu.org; Mon, 01 Jun 2020 10:26:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38384) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jflOq-0001MB-IE for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2020 10:26:48 -0400 Original-Received: from mail-oi1-x232.google.com ([2607:f8b0:4864:20::232]:37131) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jflOp-0002HR-Kj for bug-gnu-emacs@gnu.org; Mon, 01 Jun 2020 10:26:48 -0400 Original-Received: by mail-oi1-x232.google.com with SMTP id m67so9010089oif.4 for ; Mon, 01 Jun 2020 07:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eF8T+ZcRTIQ/hLUMAOL2LqkDp0ZhZMEQRMyKQbZ8dQo=; b=mBUMUz0SUg9SWUvWKSgNXnpf2CDC5lkQBKeMz00KgSNeDBIen1m2V7eYSaZHhO3ClO yQgn2mMixBUvEaa7YfixOv/rO8Z8wP3r0Wb8BYb/qhLV+DEnYXg2J9GoiG/+++PX2zIW Zqrwp3Z6h6UNG0/a2+HUBqqxDKAa8lcOiybduJpipU4hwT/uDlNIf9M1A2LpyuiUuYSG vSkgHI4QXYNHLo2XTPrl1+/v3/WYE20YKsat3NKfMTXMUU2udxscE8q3HpK0fY/Y9/2H md+QQvyEBxfVjf9njH1NqAfdKVIJsJYSodXcEW0JA1uoLV+lIIRGm/q5oyiBqpaH16FS 2DYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eF8T+ZcRTIQ/hLUMAOL2LqkDp0ZhZMEQRMyKQbZ8dQo=; b=KoytsgO6f+ITHuttB17NOQrONORhEMxdHFIFyrMBveVgzUaMDYtJ7G2uvMtFpo9J6m pKVHDspH3CM14+1xXhsy6joaqpIpxfdR8JlsISWgQV47YQLLDA2mSoj50FlQ31x6ZQXN +JCHq/7BFPIAbZv7wm05OtWLxs+/pCwhlWzSx/dPI3WO9c8QR1BuNJyF8z73CTfa+GJQ vS3z1kH8yhhzf37s1k9UfpSRIXzSliR0eMEXBqUa5A6iq7O24uvw4LWp8ARc7gRf7GCb tXENLnpUlSVHqqsErv/3CWLFfVEfV17vSyGTQcy1W9ctf1sDKqE6pDgUVcjOnmgbaArY TxXA== X-Gm-Message-State: AOAM530XsObzwHXDPUMBmGu94wGuns1B760uoSAZrtPrbkSQwPWhxMlm vMjshAocvDgUkeFqEGO61ljNamM336lNYS3kkmfQRmovDLE= X-Google-Smtp-Source: ABdhPJz0GdP+mXzLT/KUkbOqF9R3qRHrBu5xD3EJOs3TLRyB3i9QPS81hl/kur3CPWLEHynHHK/Lck4JypcmN1SHMp0= X-Received: by 2002:aca:e104:: with SMTP id y4mr13545274oig.120.1591021605929; Mon, 01 Jun 2020 07:26:45 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::232; envelope-from=nicolasbertolo@gmail.com; helo=mail-oi1-x232.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:181337 Archived-At: I have an issue regarding startup times in Windows. My configuration is Spacemacs with many layers enabled. My load-path contains 380 entries. I have profiled Emacs in Windows and found that it spends most of the startup time calling wopen(). This is because when calling (load "foo") it checks all directories in load-path for ("foo.el" "foo.elc" "foo.el.gz" "foo.elc.gz" "foo.dll"). It gets worse when load-prefer-newer is t. In my case `load-path` contains 380 entries, so every call to load will perform 380 * 5 = 1900 calls to wopen. This is very slow in Windows because its filesystem is not optimized for so many accesses to small files. I thought that a caching mechanism would help. This "cache" would consist of a mapping of files that would get probed when (load "foo") runs. It would be implemented as a hash table. The contents of this hash table could be loaded from load-cache.el files in each package directory. The directory foo-pkg could have a file load-cache.el with: foo -> ("foo-pkg/foo.el" "foo-pkg/foo.elc") [...] The directory bar-pkg could have a file load-cache.el with: bar -> ("bar-pkg/bar.el" "bar-pkg/bar.elc") [...] When a package is activated we could update the in-memory hash table by loading its load-cache.el file. Then, when (require 'foo) runs, the loading code could look at the hash table and only fopen() the files associated with the feature we are loading. This would reduce the number of calls to fopen() from thousands to ~2 in the worst case. Or we could have a big load-cache.el in `package-user-dir'. I prefer many small files because maintaining the big file when many Emacs instances could be installing or removing packages is synchronization nightmare. Of course, this feature would be disabled by default. What do you think? Nicolas