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 11:24:11 +0200 Message-ID: References: <878qyeffjh.fsf@localhost> <8734olzlws.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13224"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Helmut Eller , Ihor Radchenko , Eli Zaretskii , emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 07 11:25:04 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 1sQO8m-0003Fd-4g for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jul 2024 11:25:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQO83-0000dp-Ih; Sun, 07 Jul 2024 05:24:19 -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 1sQO80-0000dJ-PJ for emacs-devel@gnu.org; Sun, 07 Jul 2024 05:24:16 -0400 Original-Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQO7z-0004qF-4Z; Sun, 07 Jul 2024 05:24:16 -0400 Original-Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-a77bf336171so440174766b.1; Sun, 07 Jul 2024 02:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720344253; x=1720949053; 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=TcCo81PsSIKx0CqP2WVmApOM0+bmdyRlbSb6+r39CWw=; b=TlSMD3ptNkwtH6P9Y+yVY/hDCvFIQfaDRpGCq1ODKOjTjpMWU8zFgPZdE5lSW5KFYH d9qt+cYAj07wfWeBehIkkxKh3hbANPpFGNV5lGXLND6eOSIb7a1Hd9Bqk6McQ17u+Yut HQi0bL26uvPSRwKqyGv23Ps/6oU4oER8374BkkP0zOVlV4CSnB/UWUhyRwYPhDy2IyWy MDxr0PTvzuzjftno3/Mv13SaYTyPaVTy7KnMNeAF2S3UqxAyMXaWswQlbdPWghcuE3Km IsfavP5w3F9v7MSc9NfPToaiuoOnsGKykZP6zFoFDSCyohAf60jCjfVrSrHqZ3js9pMB TDsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720344253; x=1720949053; 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=TcCo81PsSIKx0CqP2WVmApOM0+bmdyRlbSb6+r39CWw=; b=Oh/tFguby0VA8dYhp6RfjRTA6aPUrD1g28MOmo42A2DecYh2bt51k8tk29lyk7ysnf rikiTyn2C/8G46gQPHmg7rQAbG+73KgPI7S5xGhzJy1Ol97IfciwMcpiX8advEdGb02E NYFdJH7Irvf1PSTlkgWKLly+/BK+mXwKZMZfGgQDd1mRFzKR7/Ut3OwEfrNMxv7BXC+u PB5fwrqa5IC3oj1XVrBtJ6iAL5+4ti2x163h1nRBBznLPyOn+8+mvyOpjcnSg5g0k8W4 IRfMfIk6vCJ3oFQV+W6GAgsW5jstACVf4H6C0xocfF9JR8q5nqdBHO/jSv4dVtnhrhgQ M8Cw== X-Forwarded-Encrypted: i=1; AJvYcCVR5hIGlZ7nqhQdju/g9StKlyx1CX+nzqIXDHh2jHY1jQ3lpPO1digkfRIyAHB60SUgrpDT/DVKxsPklnaURAHnxdcZUCpRKlKgs9vQoUPMyCk= X-Gm-Message-State: AOJu0YxSJDp1kiwrlZSZ3nDbT+G2XP7AVqOqlhNkicqrhg20jSMKiYJV liF1bvdGArb5QCntSg4AiDRXtmyZJ38AaGL9L7HAGr/BiADsfrLeNMnvfw== X-Google-Smtp-Source: AGHT+IF3R0nlDMq8GQ+US9HjvO4wGYYDv/pEiWGlINB6V4ThBVSf/8XgZ065R6TdxOWVHnTRWuCx5A== X-Received: by 2002:a17:906:1b17:b0:a77:e2b7:bc69 with SMTP id a640c23a62f3a-a77e2b7bd5bmr313020466b.29.1720344252731; Sun, 07 Jul 2024 02:24:12 -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-a77be55cfdfsm274917866b.31.2024.07.07.02.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jul 2024 02:24:12 -0700 (PDT) In-Reply-To: (Pip Cet's message of "Sun, 07 Jul 2024 08:47:57 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::62b; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62b.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:321475 Archived-At: Pip Cet writes: >> > Hm, maybe we are missing out on something here, in igc. I don't remember >> > that I balance in igc. > > Do we remove intervals at all with igc? It looks to me like they're > partially-weak objects, effectively, and we scan them strongly, > removing them only when the buffer dies? Balancing only changes the tree structure, without freeing nodes, AFAIR. But that could be wrong. It's been a long time since I looked closer at that tree. Wrt to weakness, I don't think there are weak references. The big difference to the non-MPS case is that struct interval is subject to GC at all, they are malloc'd without igc. I didn't see another way to handle their plist otherwise. Making them malloc'd roots would have meant too many roots for my taste. I have currently ca. 20.000 live intervals for example, after GC. > >> 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? > > 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 preceding tests. > > And if I modify things a little and make the preceding test fail, the > problem test doesn't seem to finish at all, and uses many gigabytes of > memory... > > Very strange. Yeah. I don't get the reason why it is allocating that much.