From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregor Zattler Newsgroups: gmane.emacs.devel Subject: Re: Indentation and gc Date: Sat, 11 Mar 2023 19:35:13 +0100 Message-ID: <87h6ur9lwe.fsf@no.lan> References: <20230310110747.4hytasakomvdyf7i.ref@Ergus> <20230310110747.4hytasakomvdyf7i@Ergus> <87a60k657y.fsf@web.de> <838rg4zmg9.fsf@gnu.org> <87ttyrwobj.fsf@localhost> <20230311111730.fatow74xnbel7t3f@Ergus> <83o7ozwju8.fsf@gnu.org> <87jzznwjh3.fsf@localhost> <83jzznwjeh.fsf@gnu.org> <87fsabwirg.fsf@localhost> <83h6urwhu0.fsf@gnu.org> <875yb7wgpd.fsf@localhost> <83bkkzwgcp.fsf@gnu.org> <87y1o3v1fr.fsf@localhost> <838rg3wf7k.fsf@gnu.org> <87v8j7v0a4.fsf@localhost> <835yb7were.fsf@gnu.org> <87r0tvuzpl.fsf@localhost> <834jqrwbgu.fsf@gnu.org> <87jzzn9pti.fsf@no.lan> <83wn3nurny.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23008"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 19:36:34 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 1pb454-0005nb-7J for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 19:36:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pb44T-00053G-9d; Sat, 11 Mar 2023 13:35:57 -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 1pb44R-000536-96 for emacs-devel@gnu.org; Sat, 11 Mar 2023 13:35:55 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pb44P-0004I1-BF; Sat, 11 Mar 2023 13:35:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1678559748; i=telegraph@gmx.net; bh=Mtn/dDWxbYESccqriUSYlOIsrX9nIctRKDwodbrWyxk=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=aFA3cbm00CxX7z24GJ7D0Yyu2Boys188p3c9mjGnlxnXzQEoLjsTeMh059vw+fY/R sFkLE8MEMkrxKVqrtwdvPIMWzscUb9wgRgxTYK7NlrOlLUbqHmqDgXsI8n9ceyEowa 869XKXSCXzl663NA1dotmGUrcu0fZZRE0bZLxubQK/jLhzxdtFwR7CXSDrP9mZ5ixA V3V+dpSQ/bj4burO/SV3zKmHDEKXbpa/Amw9jPr5nb1hDCU5pjgW2/kzbEfE+lpszh 9SlzlLKTunAJ9xi1NI3zcKJj2g00luB+tmzluClst+aJtxJApfftHVpVdKQxqBJmyS dnMbPEQli3Hng== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from localhost ([95.90.234.37]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0XD2-1qUye005FU-00wTCw; Sat, 11 Mar 2023 19:35:48 +0100 In-Reply-To: <83wn3nurny.fsf@gnu.org> Mail-Followup-To: Eli Zaretskii , yantar92@posteo.net, spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org X-Provags-ID: V03:K1:tBtm4jh+U79XHsQVVtXoWbN1/utCSNrIeuNFo+2iDFdqQzPLuo9 8+Y34fbM6umQqkVTqbzcXol0a+wSWXgiqcO5UZFmf7oXFIX9yp1AHsKRVMOCu7tueHENGgY 9SqClCSdWSjkpV2E2uFjVNb98sx5piG4O609X8PzoRKzrd0+TIk2zoqraVIIU+wwoPJKkVo H8o+1EY0xJBD+U11wQFYw== UI-OutboundReport: notjunk:1;M01:P0:445an8n18OQ=;LPJwyFHEH/ytGDZOl/YIhLdr1Y8 2YoBxo1BFxCmHai7G2TxPSC3ijFAWNQ2XwWVZTJMhfV88GWgD+2IlzpXScX+ezixX/BfLomM0 tZDOPUYzJxOfVYKh7GcwJUZ03O688NMl6w7t0E2qsFXQ+bbbaZodKloOlwXRAoG1Ac5S9/t1P 1Xjh9GsajZKtlQovNePk81Hv2E2Kkab377EnLywj4iNpt58JaAA3EK6bPKzju1NxZFvIOdHvV pPO3UbytfBRj4xAUI6QoU/qVadE+6NNXsxNb53Ub+dTnghwT2nZMQUq8kxPdnu/LUd1E5hy9C VIVIb51Dv7DroMetG6mFtAvZF3nS08dLQOrPGJtMHhtFaEnUTNLu8C0lNklgQxvkLao4uOa6k U2gHDebHIEPyQBpuQFgNmbTMt9OQmKfp8HhC3dmY0PiLfP2IHPhCRga1ffzGpAbpMH+4oh/Lg YD1NeZ2UHCa5yD6ev0RQZYt2yLJydExxhn8qwoa5SrcbVnQ8CsRBGlN0HZgEh4bZ4dvyv3qaz 5nIHhszdtde/ihXfNlM/sckUEwObINRo0IyWT8v+fRAyGLUUqsgP90fdecpXcvLqaXOes3l7E y1FE3iWBt4RZQpA3zmkHW9oBPmhTBHqwaRZCIMkzfIxf+qa0k6TzD8EA23u+7cqUkB/3Tbkpv y2QpysGmW45y3i7d2RL6eIiHtwrmWmriDsJRrv/QEe5mFHWeCg/iuPPqvpnNC9Qqt6gWmF2y6 hR5sbMAbco7XXl3+y5e1ms02V5Z3Waix0Wm2yDXVdUJDKoLq1LaJvKGiCZ+czU4J1WnUkQmQ Received-SPF: pass client-ip=212.227.17.22; envelope-from=telegraph@gmx.net; helo=mout.gmx.net X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:304331 Archived-At: Hi Eli, emacs developers, * Eli Zaretskii [2023-03-11; 19:25 +02]: >> From: Gregor Zattler >> Cc: spacibba@aol.com, arne_bab@web.de, emacs-devel@gnu.org >> Date: Sat, 11 Mar 2023 18:10:33 +0100 >> But isn't that the very reason, why Ihors gc-cons-threshold >> calculation in mid:878rg3wh2f.fsf@localhost is on the >> save side memory wise? Because it's a fraction of emacs >> overall memory consumption anyway but scaled regarding >> the total amount of memory? > > No. The limitation on the _increment_ should have nothing to do with > how much memory is already consumed or how much total memory is > available on the system. Imagine an Emacs with N MiB of memory > footprint on a system that has N+1 MiB of memory available. > > IOW, what matters is how much is _left_, not how much is already used > or totally available. At the moment Emacs does not adjust gc-cons-threshold to how much memory is left but uses a static gc-cons-threshold which is rather low. Ihor's calculations use the same conservative rather low value but scales it with overall memory. [...] > The above means you tuned the threshold to your system and personal > needs. Which is what everyone should do if they are bothered by > frequent GC cycles and too long run times of some Lisp programs they > care about. > >> Therefore I think some auto-adjustment of >> gc-cons-threshold would be nice, which would try to >> optimize for low number of garbage collection and short >> times of actual gc runs. > > "Therefore"? how does this follow from what you did? Your tuning is > static and is appropriate for your usage. Others will most probably > come up with different numbers using the same procedure. How do you > propose to make this into some kind of auto-adjustment, when how much > garbage is generated and the amount of slowdown this incurs depends on > the Lisp programs that typically run? I did it statically because I lack the ability to program an auto-adjusting solution. But it would be nice if gc-cons-threshold would be adjusted after each garbage collection in relation to the amount of time consumed in the last garbage collections. I envision an over-engineered customizable variable called gc-time-service-level-agreement which would feature two values: one for the maximum of time in seconds allowed to spend in garbage collection and another for the percentage of cases where this promise of maximum time for garbage collection must be kept. Default: (0.5 . 80) Or some such. This wished for auto-adjustment of garbage collection would help cater to the needs of users of different packages and major modes. Ciao; Gregor