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: Tue, 20 Jul 2021 11:49:32 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28919"; 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 Tue Jul 20 17:55:22 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 1m5s5Z-0007In-K6 for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Jul 2021 17:55:21 +0200 Original-Received: from localhost ([::1]:56122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5s5Y-0001K2-GU for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Jul 2021 11:55:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5s06-0006MQ-8W for emacs-devel@gnu.org; Tue, 20 Jul 2021 11:49:42 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1826) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5s02-0001Wb-J3 for emacs-devel@gnu.org; Tue, 20 Jul 2021 11:49:40 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 84D1610020E; Tue, 20 Jul 2021 11:49:35 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0B5131001F3; Tue, 20 Jul 2021 11:49:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1626796174; bh=mh5cXwnzpKCqThFgkAP9/TqFjRYdJieIEkazK1aksww=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=GlqjWhShKt45qEdPK4eQfIuatqu0akXQpSwZZ7pXMZ6bC2pO9w/fz9QyEoEW6rGT+ 4la9x2bhiMOQdiqxopSKH3WREV9PfyEUu6Uvw4cyaUBo5J/JS18KveHaWOan55MXN/ e6MzKvYu4qDwDVqkXMeXBoXeok0Lc02z9lhzOdTiRnUUz67iY4iSRbWD/8wx9lrdcO 2qpu0Yy1k0hNBLCf/MKw0rElKcTiV4DOS/kuui8qgW/JulK2QtCtP7CqZFT++zRj7Z c2qZ5604ynp77xmOrtD1f/LQ2cv+/ovUfEZ8RnMjGHrcybgO+34WT+Q4uyW8bvN4bD 2jEg1hXFtld3A== Original-Received: from alfajor (unknown [216.154.29.138]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D11841201C3; Tue, 20 Jul 2021 11:49:33 -0400 (EDT) In-Reply-To: (Arthur Miller's message of "Tue, 20 Jul 2021 08:01:03 +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:271378 Archived-At: > Not so much, but it is not so much about noticable difference, more > about not performing unnecessary computation. But Emacs is more often limited by manpower than CPU, so the impact on code complexity should not be discounted. > As the loop progresses, for every dir N, the loop does N-1 path > comparisons. These are unnecessary comparisons since when we know for > sure that the string is not added yet. Trend in Emacs seems to go > towards having more and more packages installed. This removes > N(N-1)) comparisons. I know. But you have to get to a list of at least 2000 elements before this N=B2 starts making a noticable (0.2s) difference [tested on an old 1GHz Cortex-A8. ] By the time the user has 2000 packages installed, there are several other performance problems that will be more noticeable, I'm afraid. E.g. the length of `load-path` itself will be a source of slowdown. I know 200 packages is fairly common nowadays, so 1000 or more in not an outlandish idea, and there are indeed performance issues that come up when we have many packages, but I suspect that we'll need more thorough changes to tackle this, and in any case it should be driven by concrete measurements, otherwise we'll waste our time optimizing details that don't actually matter. >> Beside the hypothetical risk that the regexp matches an `add-to-list` to >> an unrelated variable, I think this risks introducing real bugs for >> packages which use (add-to-list 'load-path ) to add >> *sub*directories. > Yes, I was aware of it, but I am not sure how to write the regex, to > avoid that risk. I don't think you can avoid that problem by fixing the regexp, but rather by `read`ing the sexp and looking at the directory it adds to make sure it is indeed one of the ones you're adding "by hand". Or maybe a better approach is to do something like what we do with `Info-directory-list`, tho it might also be tricky to "get it right". >> Of course, we can fix those problems, but unless there's a compelling >> performance argument, I think it's a waste of time. > It's quite simple to do, It's not if you want to handle correctly the corner cases, as this email discussion shows. > I don't know, at least in theory :). Maybe there's a theoretical gain. But there's a very real practical loss in time spent getting the code to work correctly and maintaining it in the future. Stefan