From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eval Exec Newsgroups: gmane.emacs.devel Subject: Re: [MPS test] Is there some customization options for `scratch/igc` feature? Date: Fri, 9 Aug 2024 01:00:21 +0800 Message-ID: References: <87sevfrnhc.fsf@protonmail.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="40278"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 08 20:28: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 1sc7sD-000ACw-VH for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Aug 2024 20:28:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sc7r2-0000Br-4w; Thu, 08 Aug 2024 14:27:16 -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 1sc6VA-0004zy-5O for emacs-devel@gnu.org; Thu, 08 Aug 2024 13:00:36 -0400 Original-Received: from mail-oo1-xc42.google.com ([2607:f8b0:4864:20::c42]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sc6V8-0003oA-11 for emacs-devel@gnu.org; Thu, 08 Aug 2024 13:00:35 -0400 Original-Received: by mail-oo1-xc42.google.com with SMTP id 006d021491bc7-5d5d4d07babso677226eaf.3 for ; Thu, 08 Aug 2024 10:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723136433; x=1723741233; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2O0IY9m3/Ju7gPowFIgB9xaI6JjqWHmMbQLhLarMam8=; b=ejCs2m2ejBqYP9UvccLvkXRk9OKbaenK8gqaAh5CZogPA1K176HVROb248FssHOC0P vOvTBsD3syGBWvBqh9jjLBS5m4HLAqAf3iBfHlGxfQ06HD69AlB7vUlUZO+SUm7pt7uJ ww6I0GC1sq5HNN3HjlT703Sw9l3ZV3+DHTI0rDG/GilthRztraIqSNwhEKIRUcvMGer7 S+UgR8oAcdPIw/0hx2L3j9oJixkP28yAAKId/MDBR2oQEnuMqwfqVaTunquv86gzbZ3N cDP4WlxCRu33mmtqZNOldRFuADLgVSnlHa8CC5NWWVx8b9VL7YuC2tneF3BBk8rVgFi/ vECA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723136433; x=1723741233; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2O0IY9m3/Ju7gPowFIgB9xaI6JjqWHmMbQLhLarMam8=; b=m/0X7tFhLCKcAqBubnoL5DC/Za2+WeovQGikn9oNSQ+W7YhFU5ks9+o+AXwFI+LmV9 TaIJwJQhvQkYt8RsRvwci7RSqYGMn9xShWDcxH5FfpfsKkcs8mxSS3As+EkKXqi92VFU WBBb1U28meiT8LhW5jHfhiwccOivbJxpTQrAJyXBndJeQ8x1siG+oWvlZV3DvRFNzvu1 XRFXWQadvWDypm8ABSjmgKFN9WwIjb+WU3lelo2vfqb/l0oPHijEclL6FgvXSEhzrz8K IakKDhNqndclu0N4K3GPMtqLpQCkU15zQBvf/4RhfWx5jvyBFmGK3Wb+xu6H8UlQ/lk0 /aUA== X-Gm-Message-State: AOJu0YzjWg5cYhIHVfP6dcmpF8gYTDk84BnDlzmsozwh/A2FOwBLko6S e3MTQQkUctiXrxOicem5U3NZWXPgCZiAgaEaTBL87XdIh6flh9O5T4/tDXYCsT4m+8PDHqZgr47 e+v+Asi3gpPw+9yaHdnCCGWGaj8G/4TAnWktYRQ== X-Google-Smtp-Source: AGHT+IHEXq4R5DUw+HGpKsFGbyvRi5NKQHGYFQxOuzNTOyGe/XJvMXPI26n/AidlySGwMfU4WKddzHUOIqdb7DyfDy8= X-Received: by 2002:a05:6820:2015:b0:5c6:8eb6:91b2 with SMTP id 006d021491bc7-5d8559eab66mr3024440eaf.1.1723136432408; Thu, 08 Aug 2024 10:00:32 -0700 (PDT) In-Reply-To: <87sevfrnhc.fsf@protonmail.com> Received-SPF: pass client-ip=2607:f8b0:4864:20::c42; envelope-from=execvy@gmail.com; helo=mail-oo1-xc42.google.com 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, SPF_HELO_NONE=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:322544 Archived-At: > Thanks again! Any news on the X toolkit problem, or can I push that > patch? Yes, thanks for your work, the patch is great. Emacs hasn't crash anymore after I applied the patch. > 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)) ? After profiling for CPU and memory, I've concluded that the lag isn't related to scratch or incremental garbage collection (IGC); it's actually connected to flycheck-mode. When I disabled flycheck-mode, the lag disappeared. I eventually discovered that flycheck was creating thousands of overlays at the very top line, which caused the lag during (forward-line). On Fri, Aug 9, 2024 at 12:26=E2=80=AFAM Pip Cet wro= te: > > "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/8e28cde297fe0b1a4f8a333e9abee17d= 76588a7c > > > 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 >