From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#68244: hash-table improvements Date: Sat, 6 Jan 2024 12:34:05 +0100 Message-ID: References: <170438379722.3921.9312235725296561206@vcs2.savannah.gnu.org> <20240104155642.B4A99C00344@vcs2.savannah.gnu.org> <8d49ebdc-9da7-4e70-a080-d8e892b980b6@gutov.dev> <08314177-5AE9-4352-94A0-641830B4094D@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 68244@debbugs.gnu.org, Stefan Monnier To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 06 12:35:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rM4xT-0005c0-PI for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 12:35:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rM4x9-0000Uh-Od; Sat, 06 Jan 2024 06:34:59 -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 1rM4x7-0000UY-T5 for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 06:34:57 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rM4x7-0004uI-LC for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 06:34:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rM4xC-0003d9-CV for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 06:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jan 2024 11:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68244 X-GNU-PR-Package: emacs Original-Received: via spool by 68244-submit@debbugs.gnu.org id=B68244.170454086113898 (code B ref 68244); Sat, 06 Jan 2024 11:35:02 +0000 Original-Received: (at 68244) by debbugs.gnu.org; 6 Jan 2024 11:34:21 +0000 Original-Received: from localhost ([127.0.0.1]:58697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM4wW-0003c5-LC for submit@debbugs.gnu.org; Sat, 06 Jan 2024 06:34:21 -0500 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:53446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM4wU-0003br-7h for 68244@debbugs.gnu.org; Sat, 06 Jan 2024 06:34:19 -0500 Original-Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2cca5d81826so3948471fa.2 for <68244@debbugs.gnu.org>; Sat, 06 Jan 2024 03:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704540847; x=1705145647; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=wj2q92k6DOg/lyrWX0gF2wtRe4KBV7uD0PfcSvEUSds=; b=l6dzCMvtBvzelmkIDvfzj84B0OV9YPtJgeDu4jj26Dl3ZAXGsTvdKBZUHQ9YjypuQG 1nwSlKn/p8EPVpj2HxdISLj/fYGmC8EX5sxW/4fSLH+4wWYRlPZF/DaHF/zzUbjSSU5X z1dEe5sHB5rJso4TXHn0XIAMlqOZiUWTz2jNNoR1RS+2N5APAouF2sQvv50CfIS1kw6T V4DQA7JIkaRfkjlKeVZSRelmvBX9qAU3VUTbrIJgjdgoeqG+MLXAi/9fBVEeQ+7ei2JG hXHfRTjs9rGcRbcNCLicmFOcHm+U67odj1A7fjew/riLAPFJ5+7C0S3gf8KcGLbTBzxA pgTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704540847; x=1705145647; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wj2q92k6DOg/lyrWX0gF2wtRe4KBV7uD0PfcSvEUSds=; b=Se4qJAidmE7HWMS9SbRv//2bW/C1Wa6R1ogX+xlO1ELkTVpcWAnKbFqdCftLsWfMI7 3GNSaz45sJfKNdSC7f2Wvrmurig0fWBEeJVXecypxq2YqJgqwtf5JWTN5srYRcVjMpsw t0e/S2tRQx60ylt7LLPrkIXdSkc7np6m84Lb4BRVt7/DAP2wDhlybamlFPQGGBGrYDcA 0QskoFqdG923qq8y6ja/fTDCvxVfnEbSSbuUn4v48T02sEj3Q7rOn+s+dCIOhG+4mv5+ RPbjvDZBchNvRCj2/aTs6rdadwzdo53fVK/DBs4Ry9qfODO4tde7Z1NbxYwYR1Xej0/T u2bA== X-Gm-Message-State: AOJu0Yx/t7Op1FMgSWkalVsN27eV4EEyTUHuUqWwci1JxUd6aeksAH0K 0XWU69V4BkQ7A7H/0fs1CWI= X-Google-Smtp-Source: AGHT+IGV9lct76O9cwch6MKlywCOCb/eQrvRb0KxKsPYWauBHazydj/0qjQbA3CD3Fb2qOKUt2LJDg== X-Received: by 2002:a05:6512:74c:b0:50e:7daf:3141 with SMTP id c12-20020a056512074c00b0050e7daf3141mr301727lfs.58.1704540847024; Sat, 06 Jan 2024 03:34:07 -0800 (PST) Original-Received: from smtpclient.apple (c80-217-1-132.bredband.tele2.se. [80.217.1.132]) by smtp.gmail.com with ESMTPSA id s3-20020ac24643000000b0050e709ca890sm501479lfo.225.2024.01.06.03.34.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2024 03:34:06 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3654.120.0.1.15) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:277449 Archived-At: 5 jan. 2024 kl. 16.41 skrev Dmitry Gutov : >> That's a good question and it all comes down to how we interpret = `consing_until_gc`. Here we take the view that it should encompass all = parts of an allocation and this seems to be consistent with existing = code. >=20 > But the existing code used objects that would need to be collected by = GC, right? And the new one, seemingly, does not. But it does, similar to the same way that we deal with string data. > So I don't quite see the advantage of increasing consing_until_gc = then. It's like the difference between creating new strings and = inserting strings into a buffer: new memory is used either way, but the = latter doesn't increase consing. Since we don't know exactly when objects die, we use object allocation = as a proxy, assuming that on average A bytes die for every B bytes = allocated and make an informed (and adjusted) guess as to what the A/B = ratio might be. That is the basis for the GC clock. Buffer memory is indeed treated differently and does not advance the GC = clock as far as I can tell. Presumably the reasoning is that buffer size = changes make a poor proxy for object deaths. Of course we could reason that growing an existing hash table is also a = bad proxy for object deaths, but the evidence for that is weak so I used = the same metric as for other data structures just to be on the safe = side. This reminds me that the `gcstat` bookkeeping should probably include = the hash-table ancillary arrays as well, since those counters are used = to adjust the GC clock (see total_bytes_of_live_objects and = consing_threshold). Will fix! > It's great that the new hash tables are garbage-collected more easily = and produce less garbage overall, but in a real program any GC cycle = will have to traverse the other data structures anyway. So we might be = leaving free performance gains on the table when we induce GC cycles = while no managed allocations are done. I could be missing something, of = course. So could I, and please know that your questions are much appreciated. = Are you satisfied by my replies above, or did I misunderstand your = concerns?