From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41646: Startup in Windows is very slow when load-path contains many Date: Fri, 01 Nov 2024 21:49:47 +0200 Message-ID: <86y122zqck.fsf@gnu.org> References: <86r08luqsq.fsf@gnu.org> <86frp1unvu.fsf@gnu.org> <86y12stv24.fsf@gnu.org> <86set0th9d.fsf@gnu.org> <86iktwt49w.fsf@gnu.org> <86cyk4t2su.fsf@gnu.org> <86a5f8t0sf.fsf@gnu.org> <86zfmizxu2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37245"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@gnu.org, acorallo@gnu.org, 41646@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Lin Sun Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 01 20:50:20 2024 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 1t6xf0-0009ST-1E for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 01 Nov 2024 20:50:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t6xem-0004y4-Vo; Fri, 01 Nov 2024 15:50:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6xek-0004wf-Sh for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2024 15:50:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t6xek-0005rX-Ju for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2024 15:50:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=1jMI7K8st/F/mWBj7RXlNWRCWzQX60c0GfFtK4Iu9nI=; b=BqMiqanXIuYL3+fEiUaNCSG4Us2MyUsB3Rg/ZF5d5tDolxqdn3wcJXWFSM/iW50ntiJTVGMQ2bgdNLAqrzfGJajGWhVJ2FIe8HzS84BtpWfankw8QMdqOjVgHn7Ncls5PnK3Ye07PgQn8HMV+Jm00sPeKo7hGqvoS+fkwt1vo/jdvlZdkGY9lZm3GmJm64s2ra3qxgtz5wJXWIjGDiOQzBvOqQQm4p4nF44TxZ/QttPOZ2uUUoZDu/182L4OSMdThiJstNKouWmTY/PgQFYhsJWPNqxHciU4Ocm7EEyTf5pvWJEteGciXqa4ipdKFwQRYySTwk6dKj0WhmrVbr+5wQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t6xek-0004Sa-DX for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2024 15:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Nov 2024 19:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41646 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch fixed Original-Received: via spool by 41646-submit@debbugs.gnu.org id=B41646.173049060017132 (code B ref 41646); Fri, 01 Nov 2024 19:50:02 +0000 Original-Received: (at 41646) by debbugs.gnu.org; 1 Nov 2024 19:50:00 +0000 Original-Received: from localhost ([127.0.0.1]:51598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6xei-0004SG-Fv for submit@debbugs.gnu.org; Fri, 01 Nov 2024 15:50:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6xef-0004S8-Df for 41646@debbugs.gnu.org; Fri, 01 Nov 2024 15:49:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6xea-0005lR-15; Fri, 01 Nov 2024 15:49:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1jMI7K8st/F/mWBj7RXlNWRCWzQX60c0GfFtK4Iu9nI=; b=JyWT/Hl8o0AA nCqx3V7370L2QD34rvnBa58TkSxSh95ncGLayR54jAo4AXTpbODLhuhxM7/W4lkul89GJIe4CC6el e48JVYYN+fmCu/M/46jrhedibfbyT+FEWsFhO4cBprNG17fGahtcZm7y2SDZpC/o/2A/xkoolgE++ z/6E0eRZnnurf/RWuSwBEJaPtrRR6nu/Q/4dNWZ314MJKOALrP+V2910P9CqkYujtxIWCFhxlJoUj s2UPm7XpIjdg2qEpQ6yGplTu99yDqrvnemXWRhOdii++rrBFFlRezq4hPW2ZlPnnHmDKbGwQCggCW LUbrTWp5YvvcZ50kuqOvwA==; In-Reply-To: (message from Lin Sun on Fri, 1 Nov 2024 17:58:01 +0000) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:294704 Archived-At: > From: Lin Sun > Date: Fri, 1 Nov 2024 17:58:01 +0000 > Cc: monnier@iro.umontreal.ca, stefankangas@gmail.com, acorallo@gnu.org, > 41646@debbugs.gnu.org, monnier@gnu.org > > > > > How will the '"file1" "file2" ...' part be created? > > > > > > For the Emacs built in paths, we can create the ( [files]) > > > during bootstrap and write to the "subdirs.el", then it will push the > > > extended (, files...) into `load-path'. > > > > I don't understand: isn't this supposed to speed up primarily users > > who have many 3rd-party packages installed? For them, what happens > > during bootstrap is not relevant. > > > > If all we want is to record the places where bundled files live, > > that's a much easier problem. > Sorry for the fuzz "bootstrap", the "bootstrap" I wanted to say is > part of building steps, like "make bootstrap", then we can build the > files list into the "subdir.el". I still don't understand: below you are talking about installing 300+ packages using package.el, so "make bootstrap" is not relevant. > Both the startup time and running time will be affected by too many > "load-path" entries. > Like the "package.el", it will add all 300+ packages' paths on the top > of "load-path" at the beginning of startup, the builtin paths will be > on the bottom of "load-path", after that a simple "(require > ')" will trigger emacs to walk through the > "load-path" from top to bottom, that leads thouthands > open-attemptions, that happened during emacs startup, or during > running time. So now we are talking not only about startup, but also about what happens after that? It is hard to discuss a feature whose goal and the problems it attempts to solve shift around all the time. Can we please formulate the goals and not change them afterwards?