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 test] Is there some customization options for `scratch/igc` feature? Date: Thu, 08 Aug 2024 16:25:06 +0000 Message-ID: <87sevfrnhc.fsf@protonmail.com> References: 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="39417"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eval Exec Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 08 20:28:24 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 1sc7s8-000A3o-HS for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Aug 2024 20:28:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sc7r1-00005K-Cj; Thu, 08 Aug 2024 14:27:15 -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 1sc5y2-00035O-VM for emacs-devel@gnu.org; Thu, 08 Aug 2024 12:26:23 -0400 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sc5y0-0006Fx-Ns for emacs-devel@gnu.org; Thu, 08 Aug 2024 12:26:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1723134378; x=1723393578; bh=6lKJrZ9Yc6ONbIMgFtK9ZzvZEYgfVDFX3xA/6MlHP1w=; 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=r66EykJDTy4w+OJDO58Gav7S+bgkMY8JQvKW9FGaSTzSgQr7XX61ZQSY061GrlFyW hfN7wJFUCh03Bx740RfxWvapS8gz7i0aKj2fK4jfp35gzEHUBlQnn3Enl+mRSVFren V6Xodn/x6SnfANunc2KrnJsGwbqq7Hbm+3ji/EMCSCzpYH9WHwguHQiCBPCaUjGDT3 SHyWMb1+DxxwZ/gh9t3wziS2pz119nV68Zgv9N5+DWbcTV5LwWS4EXhJ931qGaNK6S RH2rjuFWUVj2pjFFDGotrTxdmNF9hH8L/OD1AhlsTCmTKAMdncBCcjnP79aL6atBrY PRXZQLe3sjhcg== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5563acb8f5d09d8eccee74cf5ccba7d1400824ce Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 08 Aug 2024 14:27:13 -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:322543 Archived-At: "Eval Exec" writes: > I'm helping to test `scratch/igc` branch (commit id: 42731228d24) . Thanks again! Any news on the X toolkit problem, or can I push that patch? > At start, my cursor is in buffer's top line, I long press [down] key > and don't release, expect the cursor will move to bottom line. I feel > lag, and buffer window doesn't update until I release [down] key. I can reproduce this behavior, kind of, if I build with CFLAGS=3D"-O0 -g3 -ggdb", my usual set; in an optimized build, things seem to work out more like I would have expected. > Then I see there is some message in `*Message*`: > ``` > Garbage collecting... > Generation 0 of a chain has reached capacity: start a minor collection. > Garbage collecting... > Generation 0 of a chain has reached capacity: start a minor collection. > Garbage collecting... > Generation 0 of a chain has reached capacity: start a minor collection. > Garbage collecting... > Generation 0 of a chain has reached capacity: start a minor collection. > Garbage collecting... > (many...) > ``` What that means is that many garbage collections happen, which may be unexpected or not depending on how many "many" is... > What's the `capacity`? All allocations in MPS happen in a generation; once the total size of objects allocated in that generation reaches the "capacity", a minor GC is triggered, which may take a long time during some of which the generation is larger than its capacity. So it's a bit of a misnomer. > how can I config the `capacity`? Right now, you have to go to igc.c and edit the line which reads: mps_gen_param_s gens[] =3D { { 128000, 0.8 }, { 5 * 128000, 0.4 } }; That means that there are two explicitly-specified generations: the first has capacity ~128 MB (128000 times 1024 bytes), the second ~640 MB (5 * 128000 * 1024 bytes). There's also an implicit last generation which is "unlimited" in size and holds objects which have survived collection twice. The 0.8 and 0.4 values specify a mortality prediction for each generation: this value is updated by MPS, so it's not that relevant. It'd be nice to be able to change these values at run time, but MPS doesn't seem to offer an API to change them then: we'd have to create new pools with the new generation chain, and stop allocating in the existing old pools. The other problem is that the values are needed very early during Emacs initialization, so the usual customization options aren't available. On my branch, I've implemented a command line option which is parsed early and specifies the sizes of the generation chain, so I can experiment with them, but I haven't really gotten around to that and had a fairly embarrassing bug in my code until just now which would have rendered such experiments useless anyway. Anyway, the patch is at: https://codeberg.org/pipcet/emacs/commit/8e28cde297fe0b1a4f8a333e9abee17d76= 588a7c > I think the > lag is related to the `capacity` I don't know at which point we suspend redisplay to handle further key presses, I must confess. Can you see whether the behavior is different for (while t (forward-line 1) (redisplay t)) ? Pip