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?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 13:51:04 +0100 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87h66ng4bf.fsf@protonmail.com> <3A7135F0-64AD-4577-BDA7-ACE1E60B7364@toadstyle.org> <87jzbid6hm.fsf@protonmail.com> <87frm62s27.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8882"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Sean Devlin , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 13:52:07 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 1tSFFe-00027q-9L for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 13:52:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSFEp-0005Kb-Ct; Mon, 30 Dec 2024 07:51:15 -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 1tSFEl-0005KM-VB for emacs-devel@gnu.org; Mon, 30 Dec 2024 07:51:12 -0500 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSFEj-00083T-6R for emacs-devel@gnu.org; Mon, 30 Dec 2024 07:51:11 -0500 Original-Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aaeecbb7309so811943866b.0 for ; Mon, 30 Dec 2024 04:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735563066; x=1736167866; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=nXo/6d/mV64YCuwysrzMZyLWxdn+PR9r3SBzWaUkvYw=; b=HfjKbLUI3nt5hOGM8hxnyu6fORa4qe5iIvEh+ufaIjq9xkByqzrqKDmmtcv+/T96Sc cT7MXVs9VdjWIMeeVmC4DE3HkMymUQCjFiO5qwe/rNCKvkeTTIkUvpf0DKP1HU/J3uPg USDyegi50n7s9BV4QCpdbTl9WyeYN34zjXjp5pkLjXReulk6DPJwSCqcXE0y73NROvbO NIokObFqYxCWmy9Z2s9fPByrjNOdzjhZIoqnQq/xAq/+vuKnV125wDlow7TeTMQd2LBp ENc/rq3cOEsAO/KkMik6XfFo5eOizCCn0FqEiVB3XwHPQhnUA5yLffQ+XS2snWGb3uk/ EILg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735563066; x=1736167866; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nXo/6d/mV64YCuwysrzMZyLWxdn+PR9r3SBzWaUkvYw=; b=Uy+kkRbvbLzRtBrMyAFxfIVw2pRqQxrDAaS04JwFSszFduw73lRpprso8JrYjb6npv ALw/JDfjIXVsg7bpOrxeATyhpUAoHNgcXwQC2Z81pytUSGOb4ijpkD9TjV/cm/XtEo62 Fiu1fzoofswPKm0AK/syF84xag/H+vgWSk4ffNs3zSoNVrEqKVKvcyJDgExvLSYagPNy CbSJZvy5ThELEzU4eyz9oAcyQvKnEBxsNreRcpIPtEWWKzFiQi22INp6spXbqoymvasg g84SdblgZZSzSNZLYANMP2XxXAU34xvj1j/j5TOO4GIApVUniikfbHrXQL+N4rdTXvxb mksA== X-Forwarded-Encrypted: i=1; AJvYcCUlHCP0Llw4omXwVeTaGNZoGhAqJvwkNn+UXvHLyo5DmGiV4cPIokWS9d0Iu5kFRVUwvOIv5CUYJEJ7zg==@gnu.org X-Gm-Message-State: AOJu0Yybc4R1Q9KDUFj00YgmSK+y3ffGlmosR81QPyloBxHghDSvOoDU o9sQwnU2JEwXtpJNcua6F/fNf6iZY+NCaEe5UJ1MUyYVmsCHH+IrTbnATQ== X-Gm-Gg: ASbGncsv/LNAKcc9VvQKJ7SKnOaWXl9Ngvm77bAfxWLA84cqbMFdaWCKoT7L4VjFkAt t5pe1sRTv+3DHTzL7/hB/cWXNdXM7IcvQIbBcB5RNaLqoQuDsOEjyNFwDipzZj6lQbUV2C7PFg4 XfHvb101o7qXaGvs4CIVO2a6kaoeBpV0fUss+ow/qw7Ea2pEwHj3uKIKfcaT9k0AgadUhck42P/ iSBJoipq52o5jJlBYhvx/qkqIKUO6lCedjY93D1hkQS+NJVrAnFR91JMC4pLNf5ccY2Xw0bUOMT nt1dEOlrgUksC4GiLgsZouTWdVR2RmEcZw/NB2O3xozs1/ZyGgnBUzuT2RasoWfO X-Google-Smtp-Source: AGHT+IFifHOMpmWvgdrgjXl9xRmuuI+9xSXro0kmwTwIY8vbVhUAnHEXM15t8irDrYK+XjBK+WGmuQ== X-Received: by 2002:a17:907:c10:b0:aa6:74a9:ce6e with SMTP id a640c23a62f3a-aac2ad7fa23mr3162816566b.16.1735563065663; Mon, 30 Dec 2024 04:51:05 -0800 (PST) Original-Received: from pro2 (p200300e0b7156f000dceccb84ca1ba38.dip0.t-ipconnect.de. [2003:e0:b715:6f00:dce:ccb8:4ca1:ba38]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f016babsm1467889066b.169.2024.12.30.04.51.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 04:51:05 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Mon, 30 Dec 2024 07:16:23 +0100") X-No-Archive: Yes Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x636.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-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 X-Gmane-Expiry: 2025-01-13 Xref: news.gmane.io gmane.emacs.devel:327417 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> Speaking of running with a "normal" config: something about my >> configuration makes buffer_step (the balance_intervals call, in >> particular) take forever, to the point the mps build becomes unusable. >> The buffer in question, when I caught it, is an M-x shell buffer of size >> 8 MB, so I don't understand why it's taking so long. >> >> Still investigating, but skipping the buffer_step seems to help. > > balance_intervals means text properties. The only candidate I see in > comint/shell is ANSI escapes. That could be turned on/off with M-x > ansi-color-for-comint-mode-xy. Only as a workaround, and maybe to check > if it's that. > > What I do in buffer_step in idle time is basically one step of what the > old GC does in sweep_buffers. > > My expectation was that balancing a tree couldn't take long, and that > this is not called often enough to be a problem if were expensive. Both > wrong, as usual. > > Not calling balance_intervals is, BTW, not a catastrophic problem. if > one does anything leading to a graft_intervals_into_buffer, w called in a lot of places in editfns.c and insdel.c, that balances the > tree. And if not, the tree might become slower for lookup (redisplay), > but it still works. > > It's BTW well possible that I myself put that balancing into > sweep_buffers because of redisplay, I seem to remember that. The > interval tree has always been a source of fun. I hope, some day, some > kind soul will eradicate it like the GCPROs. > > In any case, what's a solution? > > Right now I'm tending to put the balance_intervals in an if so that one > can turn it on/off with a Lisp variable. Default would be to not to balan= ce, > because I think the problems with degenerated interval trees in > redisplay where rare, and I don't remember problems outside of > redisplay. But that was an awful long time ago, OTOH. > > That would give us more time to think about a possible strategy to solve > this. > > WDYT? Patch for that attached. I'm now running with that. I tried to look at the history of intervals.c to see too which degree the intervals tree is behaving better than decades ago (I think Stefan Monnier said it's better), but I couldn't really determine that. Too much has changed. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Make-balancing-buffer-intervals-optional.patch >From 0aa8b2f483da11bfd6a6397c56182b5877cb779e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= Date: Mon, 30 Dec 2024 13:41:40 +0100 Subject: [PATCH] Make balancing buffer intervals optional * src/igc.c (buffer_step): Balance intervals only if igc__balance_intervals is true. (syms_of_igc): New DEFVAR_BOOL for igc__balance_intervals. --- src/igc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/igc.c b/src/igc.c index 39158b38f05..964723ce315 100644 --- a/src/igc.c +++ b/src/igc.c @@ -3697,7 +3697,8 @@ buffer_step (struct igc_buffer_it *it) buffer_it_next (it); struct buffer *b = XBUFFER (buf); compact_buffer (b); - b->text->intervals = balance_intervals (b->text->intervals); + if (igc__balance_intervals) + b->text->intervals = balance_intervals (b->text->intervals); return true; } return false; @@ -5100,4 +5101,8 @@ syms_of_igc (void) don't do something when idle. Negative values and values that are not numbers are handled as if they were the default value. */); Vigc_step_interval = make_fixnum (0); + + DEFVAR_BOOL ("igc--balance-intervals", igc__balance_intervals, + doc: /* Whether to balance buffer intervals when idle. */); + igc__balance_intervals = false; } -- 2.47.1 --=-=-=--