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 18:54:42 +0300 Message-ID: <83a5s8kocd.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> <83edhkmfax.fsf@gnu.org> <87ttqghwcs.fsf@> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9799"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Bidar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 24 17:56:01 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 1qvJlB-0002M4-Cg for ged-emacs-devel@m.gmane-mx.org; Tue, 24 Oct 2023 17:56:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvJkM-00063v-Ul; Tue, 24 Oct 2023 11:55:10 -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 1qvJkF-00061c-6K for emacs-devel@gnu.org; Tue, 24 Oct 2023 11:55:04 -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 1qvJkD-000290-VV; Tue, 24 Oct 2023 11:55:01 -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=XwPY8jBFipd33KqXYKNqCMrL/f9Gug8liZmh6o8FBvQ=; b=ehA0b+/YCr8JEKmWEUqx mwk1iF+y2jnKAVQOrNWDpPvQCvB/UqUA1XZTQsVc+/iSZ2aFpj/xaQoasHpmji0P6ZK0sg1/LyrLs lm5fT+uzvVLIolSeZJot9MgnNULJJYBwb4gZd7Jul2qvXrWw92pgs2pTwVKWJytozqTCWkmmEWRq+ mnJg9AoxEZzkuuSZXAdihFY+YRx7A9H2ZP+WWHlLch063wLnbkXVsLWa06UZAQyP9OkC5ROSZ/ddl /iTfT+bO3NCYSoqthxMRhXvOiiPUFJssTCXbTL4dzaIsaaywjB1c9KH0/7F7MWn+1hSmLOiZAvQwu OfAGzSg/1ZiSOw==; In-Reply-To: <87ttqghwcs.fsf@> (message from =?utf-8?Q?Bj=C3=B6rn?= Bidar on Tue, 24 Oct 2023 18:29:55 +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:311804 Archived-At: > From: Björn Bidar > Cc: stefankangas@gmail.com, gregory@heytings.org, rms@gnu.org, > emacs-devel@gnu.org > Date: Tue, 24 Oct 2023 18:29:55 +0300 > > > 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. > > I get that point but in this case we talk about doing something > slightly different to not load cl-lib while eventually cl-lib is loaded > anyway. How is cl-lib different from any other package that is extremely likely to be loaded close to a beginning of a production session? The rationale for not loading anything we don't strictly need is that different users have different use patterns, and Emacs can be used in different modes: a GUI or TTY interactive session (with various user customizations that load packages), a batch command, in a script using --script, as a daemon, etc. Each one of these needs different optional modes needs to load different packages; preloading things that are frequently loaded is therefore likely to load stuff needed by some other mode/configuration, and that is simply not clean, besides the fact that it "punishes" users by having them load stuff they don't need. E.g., my production session loads no less than 214 packages right when it starts. Why would we do that when everything works without it? What kind of problem are we trying to solve here? I see no problem. > >> 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. > > >From my pov Emacs start up time or speed is more limted by Emacs being > single threaded rather than loading a few kbs of code that will be > loaded later anyway. So our POVs differ. Lat's agree to disagree about that.