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: weak hash tables Date: Sun, 07 Jul 2024 08:47:57 +0000 Message-ID: References: <878qyeffjh.fsf@localhost> <8734olzlws.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="7217"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Helmut Eller , Ihor Radchenko , Eli Zaretskii , emacs-devel@gnu.org To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 07 12:37:34 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 1sQPGw-0001hh-7l for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jul 2024 12:37:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQPGG-00007b-S4; Sun, 07 Jul 2024 06:36:52 -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 1sQNZ0-00085L-SK for emacs-devel@gnu.org; Sun, 07 Jul 2024 04:48:06 -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 1sQNYz-00035f-2x; Sun, 07 Jul 2024 04:48:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1720342082; x=1720601282; bh=vBGPfNy0jHvXCYIKNcNKrWTJx3fTw3IimFldj/Oml1A=; 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=gNL4Cx7B50xV9CMUTfCvtsy3qZUsGDohN3DIAD/pIrAGzMGwdkJFDZ/ekjK22E+/0 DzCG5R03BYCc5YELNY85D53eGknGu0Iiwn9mta/gstAt73JqL3t4D6WhWqS6DL6nSg D8BY40UCJsFojkVB1OQhMgueuyhD0kBw9ihBSiOInlGXwuhNK+ITU3O3W8oHh1OeRw 8GzsusSmmUdgAFjFHStaCnj3CK/Xxc76vHXblb3fhStG71NdA7uGIfaaMOivOnXnL+ 1OUpdp1rYJb2c68eKnGBs72oia+0deB9tg2h1MjhNTnvnqlt/BqV7eptq7IM0JGzt1 H02haU2OaCsMw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e5d073e264823830352fe7f4451afbefd31f31ce 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: Sun, 07 Jul 2024 06:36:51 -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:321477 Archived-At: On Sunday, July 7th, 2024 at 08:24, Gerd M=C3=B6llmann wrote: > Gerd M=C3=B6llmann gerd.moellmann@gmail.com writes: > > Helmut Eller eller.helmut@gmail.com writes: > > > On Sun, Jul 07 2024, Pip Cet wrote: > > > > What's going on here? > > >=20 > > > How likely is a bug in the tree balancing code? I find it rather odd > > > that the old GC rebalances interval trees during the sweep phase. > >=20 > > I'd say not very likely but of course not impossible. > >=20 > > The problem with the interval tree is that it isn't self-balancing like > > say a red-black tree. It isn't using an algorithm that I recognize. > > Already when I wrote the new redisplay code it was a problem that the > > tree sometimes degraded for which I added more calls to balance it. > >=20 > > Both string and buffer intervals are balanced in the swepp phase of the > > old GC I see. > >=20 > > Hm, maybe we are missing out on something here, in igc. I don't remembe= r > > that I balance in igc. Do we remove intervals at all with igc? It looks to me like they're partial= ly-weak objects, effectively, and we scan them strongly, removing them only= when the buffer dies? > I've also run the slow version of the test, when it happens to be slow > which is a mystery, under Instruments, which is kind of the shitty > equivalent of perf on macOS. >=20 > From the little I see there, something I don't know is concatenating > strings, and adding text properties to them. This allocates conses and > intervals. The allocation point is running out of reserved memory, > mps_ap_fill is called, and MPS scans like mad. That's where the time > goes. Alone 13% of the whole time is spent in fix_cons for example. >=20 > More I can't see with the tools I have available here. Maybe intersting > could be that balance_intervals doesn't show up here, but that could be > due to the differences in barrier implementation on macOS. >=20 > And the good question is of course why is the test fast when invoked > like Pip showed? Well, the backtrace that's scanned lists all tests that have previously run= (and their results), and thus it's a lot larger when there are more preced= ing tests. And if I modify things a little and make the preceding test fail, the probl= em test doesn't seem to finish at all, and uses many gigabytes of memory... Very strange. Pip