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: MPS: weak hash tables Date: Sun, 07 Jul 2024 10:24:10 +0200 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="40316"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , 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 Sun Jul 07 10:25:13 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 1sQNCq-000ANU-VH for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jul 2024 10:25:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQNBy-0002dc-Rd; Sun, 07 Jul 2024 04:24:18 -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 1sQNBx-0002dS-6K for emacs-devel@gnu.org; Sun, 07 Jul 2024 04:24:17 -0400 Original-Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQNBv-0004h3-Kw; Sun, 07 Jul 2024 04:24:16 -0400 Original-Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a77dc08db60so172606166b.1; Sun, 07 Jul 2024 01:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720340652; x=1720945452; darn=gnu.org; h=content-transfer-encoding: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=awB5tk3+l/Ghf+yShFuebp5E4h5hNZqaJj0ar3mR+DU=; b=D8nF23Ji450KEI8T7h1qEU7oFD/5Igy9/u9/bLMqhEhndxSi5T5JA3kaomYAgav+18 pz98LOVdUtZ5tcEWDOsgzb4wo+nHtE7syFrMvXbC8Axlf43cssfeM8qUXskcVzjI4Bb6 ADwabsdJkkbZ0PNTroRfPtIl9+KuzYCb74LE3v2Ccgv19AFfAaeRh05ys1qP8Evqlue3 I6y4weQNU5jqy2dDaSOlRvSzwkxRgVpjbgvmgR+NEE01TjAoyY9YFCixlFMk2UIzJ55w P4puLgY7LGVtxwHhrxiJ3gXjIREqm7qqdXmylel2iaYdrk6urfjp139tDNrGGfotwaNV Qkzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720340652; x=1720945452; h=content-transfer-encoding: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=awB5tk3+l/Ghf+yShFuebp5E4h5hNZqaJj0ar3mR+DU=; b=JAZjThe9rnP09e49vxCdIBYcFYauyw8RbBG0YFuTbX2jh/yKTnNtEyli/cj2AQQylh M720eSg5jfVwkAPtHik1OKTRLD3f9wYZKJe/6F0gkWu1rPfCe7WrESNWmruER1ceSCpo UpmMFvUmDHFjQzRSbtMJUPWAyE/Tfht8kfW+cVkEk3+qNm45IfSQQJ2CmM7zO1dZaP/g ZkXOqesHR/TQjRZyfb2dQh3YLZCSzGiQHgovf/8wffN2iuWtZxfUMNrkg589ybFCv78p WQwtmDytluBpHw1qQ6hqemWuvCaNDayhNPbYRaFSzauuah5JuMVA1VXF4dD8U6aFYx/a L28w== X-Forwarded-Encrypted: i=1; AJvYcCUsgYJ5mWfN7cCFz/iN6Q9KAZ2dhsqurjzaPZ0XQd2Wc3uyeYFNWnM7S2rgKgJQ1O7p1kVqPAWuWTGIehcznHc9h9t9MU+bBRqyTZGqzJUL14s= X-Gm-Message-State: AOJu0YwHV5v+E4rtc1PekNiuxU5AQWcl6/FgTxH9+4KxHExmFufQD/ij NycPvpcWw0vp2VbvARAKzlPZvX3EBcrEU8uT7vyPhgPLX4SuZOMmBiTtrg== X-Google-Smtp-Source: AGHT+IHrGaRol0pM3U72LEPJC4SNGIRCxBE2Fxav3auNY+OGcPJ/Sn5irhNN9vYfnNCZBzr+gIWObQ== X-Received: by 2002:a17:906:e286:b0:a77:de2a:aeee with SMTP id a640c23a62f3a-a77de2ab23dmr326141166b.43.1720340651950; Sun, 07 Jul 2024 01:24:11 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a778.dip0.t-ipconnect.de. [79.227.167.120]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a77efd6a182sm48801966b.190.2024.07.07.01.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jul 2024 01:24:11 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Sun, 07 Jul 2024 10:10:45 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62d.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 Xref: news.gmane.io gmane.emacs.devel:321473 Archived-At: Gerd M=C3=B6llmann writes: > Helmut Eller writes: > >> On Sun, Jul 07 2024, Pip Cet wrote: >>> What's going on here? >> >> 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. > > I'd say not very likely but of course not impossible. > > 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. > > Both string and buffer intervals are balanced in the swepp phase of the > old GC I see. > > Hm, maybe we are missing out on something here, in igc. I don't remember > that I balance in igc. 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. >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. 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. And the good question is of course why is the test fast when invoked like Pip showed?=20