From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#68244: hash-table improvements Date: Fri, 5 Jan 2024 17:41:47 +0200 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15550"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , 68244@debbugs.gnu.org, Stefan Monnier To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 05 16:43:22 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 1rLmLx-0003lW-Hn for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 16:43:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLmLg-000489-Cb; Fri, 05 Jan 2024 10:43:04 -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 1rLmLa-00047v-JA for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:42:58 -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 1rLmLa-0002u9-Ak for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:42:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLmLe-0000JY-CY for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 10:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jan 2024 15:43: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.17044693241133 (code B ref 68244); Fri, 05 Jan 2024 15:43:02 +0000 Original-Received: (at 68244) by debbugs.gnu.org; 5 Jan 2024 15:42:04 +0000 Original-Received: from localhost ([127.0.0.1]:57631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmKh-0000IC-Oc for submit@debbugs.gnu.org; Fri, 05 Jan 2024 10:42:04 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:41785) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLmKf-0000Hh-J2 for 68244@debbugs.gnu.org; Fri, 05 Jan 2024 10:42:02 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 151655C00DF; Fri, 5 Jan 2024 10:41:52 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 05 Jan 2024 10:41:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1704469312; x=1704555712; bh=M163gRd+WpItyhKE+HALQ5hqtWxfMTh20wI1Mfs8PKg=; b= irQhwz5FHlbpf5nmwbQ0Sb5E5zh72HfItFtgGT6cuo9QLQzA1TsJLkWGid8o48nU MHXSIBAtZ12Oyjc266PunVAsGkoDf5rMsve846G0pnw6mZk9RWj7gy5tSnrypoP2 YEVJyj3H+YkTjDDa146SsTAzPne88POq7o6uCNk5nwZVTdnCTJ4IigR/g8BS2TCL FCTg1tY8LEgU4UEzGM0aGWWJBoaYPf2CbAB9TbEOIvk1izH6y+FLImc2TuDILhsY gaYh4G+mMmB5E54jZEonM61RbQSxemWMulryYGgTlYjvbyjASKmOr3g4yjukRrNP dJkCtKtD78s40D6MmHR4Zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704469312; x= 1704555712; bh=M163gRd+WpItyhKE+HALQ5hqtWxfMTh20wI1Mfs8PKg=; b=v L1RmtnhBKG3QppJhzGkB2v+JmTk6m43ofGdm04jSlOMfS0msPyG6jvetAPzzK/0b s55QzWQ3OViF7D6LzbvEnQCPVEFkcI40ijcuVpuART/M5ep/DrNQwi9GaB9WgCdq G6yO2BME3GR8tecjCFYa6HNGod6Vy2uFv/oKEeNVQVxWxjnvd4ZoNAsTsJ8DmMty NAFuo3e3LXV8PjXZebDbPI8ZMo7cKNm/KpkqOWgBlHnkxbX+P1GVQ25Ng+7Gadon yiwA6iW6OByvjvJcNzxi244OTuEBUDfKZdP3G6BKvyo9A7CMKPq0fbMSy6yM6XVG K6DMtI3Sm6gjrYsX+snsw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegledgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 Jan 2024 10:41:50 -0500 (EST) Content-Language: en-US In-Reply-To: <08314177-5AE9-4352-94A0-641830B4094D@gmail.com> 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:277397 Archived-At: On 05/01/2024 12:33, Mattias Engdegård wrote: > [ replies to questions asked elsewhere ] > > 4 jan. 2024 kl. 18.32 skrev Dmitry Gutov : > >>> +hash_table_alloc_bytes (ptrdiff_t nbytes) >>> +{ >>> + if (nbytes == 0) >>> + return NULL; >>> + tally_consing (nbytes); >>> + return xmalloc (nbytes); >>> +} >> >> Sorry if it's a stupid question, but if the operation doesn't add any Lisp "garbage", why increase the consing counter? That is likely triggers more GCs earlier which otherwise might not run, and if there are no slots to GC, it seems like they would run in vain. > > 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. But the existing code used objects that would need to be collected by GC, right? And the new one, seemingly, does not. 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. > These ancillary allocations are parts of the hash-table object: they are allocated and freed at the same time as the mother object, and subject to the same `consing_until_gc` accounting. > > The new code is radically more efficient when growing tables, because we can free the old vectors immediately (and adjust consing_until_gc accordingly) instead of leaving it as garbage waiting to be collected. This provides several benefits in itself (GCs are made less often, we can re-use hot memory). Not having to traverse them in either the mark or sweep phases is another big gain (the key_and_value parts still have to be marked, of course). 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.