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.devel Subject: Re: Lisp files that load cl-lib in problematical ways Date: Tue, 24 Oct 2023 14:27:02 +0300 Message-ID: <83edhkmfax.fsf@gnu.org> References: <835y38qvlg.fsf@gnu.org> <87bkcx6eci.fsf@dataswamp.org> <83ttqnm4ti.fsf@gnu.org> <83lebyu5yx.fsf@gnu.org> <4684f43123d7dee59461@heytings.org> <835y2xo1a5.fsf@gnu.org> <4684f4312391906f6101@heytings.org> <831qdlo084.fsf@gnu.org> <87cyx4jva9.fsf@> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8226"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org To: =?iso-8859-1?Q?Bj=F6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 24 13:28:19 2023 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 1qvFa7-0001vI-Dy for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Oct 2023 13:28:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvFZ8-0006wu-Bz; Tue, 24 Oct 2023 07:27:18 -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 1qvFYz-0006vj-J0 for emacs-devel@gnu.org; Tue, 24 Oct 2023 07:27:10 -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 1qvFYx-0002Lp-P1; Tue, 24 Oct 2023 07:27:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=DPd0vFdiAyMb5WKHsGiYP4qw1c0n3UFCtdBX6pdiJNs=; b=LPgjZYJb3e3wjtRK4WI3 5+bUxaKiURES/Va+6hPJBuKps0/YCyjZAWt24NlqwdFyhTUKafat51mpOhAfM1u3tIZkwngW4l67M 4t/+3gYFAGBKHYX30vyZA5AQi1KKjiQzcmjL4cdG3so0eLOr26TLUEqVIupX0qNfVcd8IKLbkRTM+ 4qbk7VE485XMdx5vWJTGfrSlcQOCnqm7ZmCdhGZNHmVxZwhQ9Q0PxfWlgurGQZYcU1D4uZhV4N5tw HX3cPQs1KE1VDdRzT3E7V1p2wW1zqv/f04CAbDrhQudW39sDG5R/ngJkKYMV7KEMcesw+Auo94uyG Zw+FSpXANAWFKg==; In-Reply-To: <87cyx4jva9.fsf@> (message from =?iso-8859-1?Q?Bj=F6rn?= Bidar on Tue, 24 Oct 2023 11:10:06 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311772 Archived-At: > From: Björn Bidar > Cc: Eli Zaretskii , Gregory Heytings , > rms@gnu.org, emacs-devel@gnu.org > Date: Tue, 24 Oct 2023 11:10:06 +0300 > > Stefan Kangas writes: > > > Eli Zaretskii writes: > > > >> Preloading unnecessary stuff is a slippery slope that once we start > >> there's no way of knowing where we end. So let's not. > > > > AFAIK, the main drawback is increased memory consumption. The main > > benefit is that Emacs starts faster. > > About how much memory are we talking here? All this sounds like talk > about micro optimizations. If we ignore such "micro optimizations", we will quickly bloat Emacs, since those small amounts add up. We have a lot of relatively small potential additions that we make a point of not adding, because if we decide adding one is okay, then why not add all the rest? We don't add such stuff to subr.el or to simple.el or to files.el, and keep them separate, precisely because adding them all will not be insignificant. The only way of keeping this kind of bloat at bay is to resist adding anything, no matter how small, because, like I said, it's a slippery slope. > Emacs speed is more limited about it being single threaded most of the > time than anything else. I don't see the relevance, sorry. We can work on making Emacs faster without bloating it.