From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: 28.0.50; Proposal: slightly more efficient package-quickstart.el Date: Fri, 23 Jul 2021 10:36:34 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20549"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 23 16:37:23 2021 Return-path: Envelope-to: ged-emacs-devel@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 1m6wIk-0005Ak-Ao for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jul 2021 16:37:22 +0200 Original-Received: from localhost ([::1]:48624 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6wIj-0003YU-Bw for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Jul 2021 10:37:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51470) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6wI6-0002Ah-U6 for emacs-devel@gnu.org; Fri, 23 Jul 2021 10:36:43 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49058) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6wI4-0000il-3E for emacs-devel@gnu.org; Fri, 23 Jul 2021 10:36:41 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5399B440F4F; Fri, 23 Jul 2021 10:36:37 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DC9C1440E81; Fri, 23 Jul 2021 10:36:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1627050995; bh=7xQUrP5uTPBPC/yD3drA+L6JTyZ0r2QKhafxnVg932E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=W77fK0ZDHQL3wSMG4lzDvtE3gZZa2BCO57FEjv7bjLgRVj3ktTEi7W338fSprfFRE IuH0QDKtcnRJrk8V5tyPEypG8V4YBVJOIoFneuc7sKTP8t0LzoyCks94sW9bxztbAp lf1GcaYg7HQGwsNdBX38dHgp9GNkMvQ4mQ6DWhyYlaAGIIZrabEsE9co98pwsJpmtG QZ0ODR40Y0aZF0sgvjE13rN8K18xuh+7B+sIc8u7+o7U6lE4Tfn89JOaRg5Rb7nCdn DhP0yoZJKQABBpqcfkGp1Z+m7lJkAkZlcPeRVqGxMKRW1huXbaPn1MzG1EtXdzbKDt QVCAeAGrwnE4g== Original-Received: from alfajor (unknown [216.154.29.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B1EB81203C4; Fri, 23 Jul 2021 10:36:35 -0400 (EDT) In-Reply-To: (Arthur Miller's message of "Fri, 23 Jul 2021 00:38:36 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:271498 Archived-At: >>> Not so much, but it is not so much about noticable difference, more >>> about not performing unnecessary computation. > I agree that simplicity and code clarity is important, on many > levels. But maybe we can have the cake and it it too, as you said > for wdired? In the case of wdired there was a concrete gain. Here it's only hypothetical, so the positive motivation is quite different. Also `package-quickstart` is fairly tricky to troubleshoot (beyond removing or refreshing the file). To the end user it's largely a magical button, so it's really important to make it work reliably. IOW the incentives are strongly opposed to your proposition. > Last weekend I tested actually myself to restructure how my packages are > loaded. I noticed that init time increased after I added ~100 packages, > just for test, and I didn't required anything of that into Emacs. So I > tested the idea to put all .elc file into a single place and skipp in > entirety this monstrosity of load-path that results after 200 packages > are loaded. I got it to work to a degree, it least I got running Emacs, > native compiler not complaining and most packages loaded, but I also got > some cyclic dependency, notably for dired and semantic of all things, > that actually rendered entire session unusable for the most part. I'll > leave that for another day when I have some more time. Moving the .elc files to a separate (short) list of directories indeed one way we could address the situation where there are too many entries on `load-path`. Another way would be to scan `load-path` "once" and populate a hash-table from that, after which (load "foo" ...) could be sped up by looking up "foo" in the hash-table. Still, that presumes that finding a file is the main issue, but I don't know if that would indeed be true. > (when (re-search-forward rx-path-beg nil t) > (goto-char (line-beginning-position)) > (setq temp-point (point)) > (forward-sexp) > (when (search-backward file nil t 1) > (goto-char temp-point) > (kill-sexp))) I'd do something like (while (re-search-forward "^(add-to-list" nil t) (goto-char (match-beginning 0)) (let ((start (point)) (x (read (current-buffer)))) ...))) -- Stefan