From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Tue, 10 Dec 2024 14:39:54 +0100 Message-ID: <87cyhzmzbp.fsf@telefonica.net> References: <878qwuitbu.fsf@yahoo.com> <87jzcajrnz.fsf@protonmail.com> <86o71mfhox.fsf@gnu.org> <87frmyjn9j.fsf@protonmail.com> <86ldwqfcqv.fsf@gnu.org> <87a5d6jgim.fsf@protonmail.com> <86a5d6f7bn.fsf@gnu.org> <871pyijctd.fsf@protonmail.com> <8634iyf257.fsf@gnu.org> <8634iwex8q.fsf@gnu.org> <86wmg7bso1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3862"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:WIWxkDMpLi1NETQBD/W2y9Qy+ls= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 10 14:51:22 2024 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 1tL0e1-0000rB-Mb for ged-emacs-devel@m.gmane-mx.org; Tue, 10 Dec 2024 14:51:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tL0dV-0004H8-0M; Tue, 10 Dec 2024 08:50:49 -0500 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 1tL0TB-00024p-ML for emacs-devel@gnu.org; Tue, 10 Dec 2024 08:40:09 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tL0T9-0004J2-QV for emacs-devel@gnu.org; Tue, 10 Dec 2024 08:40:09 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1tL0T7-000AAu-Gr for emacs-devel@gnu.org; Tue, 10 Dec 2024 14:40:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 10 Dec 2024 08:50:47 -0500 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:326288 Archived-At: Eli Zaretskii writes: > Maybe so, but why is such a long wait a problem? GC _works_, and > works well. Working on certain projects with lsp-mode is a miserable experience due to all the random pauses. My perception of the past week or two using igc is that those pauses are much less jarring, if perceptible at all. I need more time to make a definitive judgment, though. As code edition evolves and Emacs is put on more demanding tasks the limitations of GC become more obvious (and CPUs are not getting faster anymore). Apart from that, I'm convinced that there is quite a bit of evolutionary pressure exerted by GC on the Elisp package ecosystem: something that works too slowly or is too bumpy does not atract users and die. Others may end devoting a lot of effort to optimize GC usage and when they finally work "well enough" (for some generous interpretation) most potential users already made their mind (flx.el is a paradigmatic case) or the package author simply stops working on it, sometimes without making the first release. GC also diminishes the benefits of native-comp and other performance enhancements: no matter how fast you make your Elisp execution engine, the time taken by GC stablishes a hard limit. But the "stop the world" mode of GC operation makes user experience quite worse even if the total time to perform a task is smaller.