From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: MPS: commit limit Date: Tue, 16 Jul 2024 16:32:50 +0000 Message-ID: References: <87ed85xj67.fsf@gmail.com> <8734olxcdj.fsf@gmail.com> <87bk2xweng.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38529"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Ihor Radchenko , Eli Zaretskii , emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 16 20:16:30 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 1sTmj0-0009j5-9n for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Jul 2024 20:16:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sTmiI-0001cS-Sl; Tue, 16 Jul 2024 14:15:46 -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 1sTl74-0005z0-Js for emacs-devel@gnu.org; Tue, 16 Jul 2024 12:33:15 -0400 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sTl6y-0007fz-CZ for emacs-devel@gnu.org; Tue, 16 Jul 2024 12:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1721147581; x=1721406781; bh=obQJ5tl2xWhZ6mOYrbdqjCMvvkxwmsV+zV5JWyfuYvQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=W0fKp2M9QVIg392rGXoUYGXuAv9ZYZ2yBjWt6EFogCPx7JiAoJq+9mwuwIoUcICXO dx6v3t6DiNGbjypFomZd0wmpIsu/SQPv57FV4NXDCagfuQMMm4ifzJFSO0OLSdyjAI vx9klC+gxCkJPEYKULIR3WV+QoyLc3Xg/tUPnRzq2kntmCoG1DyijrzV0i/OPODKcf Jr5cCV+MnYoqH6zVVzzlxHXvrp7eE/qE+eU+gamRs1eQTUAwGW7rhQtCcOl2eS96OU olNlOs2s2TqukB1KHH381NOAoCb+VatCwQROw88nLsUJxRh4L3XrXUVtpY9/3BKrrB PqAlrxyDBOiKw== In-Reply-To: <87bk2xweng.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 840f8253cbdc4252db8394f7cd339ba152c79a96 Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.protonmail.ch X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 16 Jul 2024 14:15:41 -0400 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:321730 Archived-At: On Tuesday, July 16th, 2024 at 15:16, Helmut Eller = wrote: > On Mon, Jul 08 2024, Gerd M=C3=B6llmann wrote: >=20 > > Sometimes it works just fine, sometimes not. For example, with 1 << 29, > > I get a nice memory full when dumping, always. With 1 << 30, only the > > expensice ert-test triggers something, namely the assertion in MPS. >=20 >=20 > This patch adds a igc--set-commit-limit function. It doesn't fix the > problem with the assertion. People who use the hot MPS build will > probably see a normal memory full error and probably have to quit soon > after that. The others see the failed assertion and abort immediately. > So the end result will not be much different. I'm not sure about that one. Should we really expose a function we know to = be buggy in the single implementation that people are likely to use? I don'= t understand why you made it invalid to set the commit limit to SIZE_MAX, b= ecause that is a valid commit limit, and what the MPS explicitly suggests y= ou should set the commit limit to. > The other two patches are minor cleanups. Those look good to me Sorry, again, for taking so long with the current pat= ch set, which touches this same code (and indeed does the same thing for ig= c_assert()...) BTW, are you still running performance tests? I've found it helps a lot to = play with the "pause time" and "initial area size" parameters. I can run pi= digits in 9 seconds now, on my Android phone (optimized build and all that)= :-) And unlike the commit limit, setting the pause time appears to work, so may= be we should expose that to. I don't know how to expose the generation chai= n settings yet, since they're set at pool creation time. Pip