From: Dmitry Gutov <dmitry@gutov.dev>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
68244@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#68244: hash-table improvements
Date: Fri, 5 Jan 2024 17:41:47 +0200 [thread overview]
Message-ID: <f2bf750d-73f0-4aa4-8dd6-11407e20e83e@gutov.dev> (raw)
In-Reply-To: <08314177-5AE9-4352-94A0-641830B4094D@gmail.com>
On 05/01/2024 12:33, Mattias Engdegård wrote:
> [ replies to questions asked elsewhere ]
>
> 4 jan. 2024 kl. 18.32 skrev Dmitry Gutov <dmitry@gutov.dev>:
>
>>> +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.
next prev parent reply other threads:[~2024-01-05 15:41 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <170438379722.3921.9312235725296561206@vcs2.savannah.gnu.org>
[not found] ` <20240104155642.B4A99C00344@vcs2.savannah.gnu.org>
2024-01-04 17:32 ` scratch/hash-table-perf 2d28042f56a 19/35: Use non-Lisp allocation for internal hash-table vectors Dmitry Gutov
2024-01-05 10:33 ` bug#68244: hash-table improvements Mattias Engdegård
2024-01-05 15:41 ` Dmitry Gutov [this message]
2024-01-06 11:34 ` Mattias Engdegård
2024-01-06 11:51 ` Eli Zaretskii
2024-01-07 3:13 ` Dmitry Gutov
2024-01-07 5:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-07 15:39 ` Dmitry
2024-01-07 18:36 ` Mattias Engdegård
2024-01-07 19:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 18:26 ` Mattias Engdegård
2024-01-09 0:33 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 10:26 ` Mattias Engdegård
2024-01-13 20:06 ` Mattias Engdegård
2024-01-04 16:27 ` Mattias Engdegård
2024-01-04 16:39 ` Eli Zaretskii
2024-01-04 17:02 ` Mattias Engdegård
2024-01-04 17:45 ` Eli Zaretskii
2024-01-05 11:34 ` Mattias Engdegård
2024-01-05 17:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 11:46 ` Mattias Engdegård
2024-01-09 21:51 ` Stefan Kangas
2024-01-12 15:42 ` Mattias Engdegård
2024-01-14 22:08 ` Andy Moreton
2024-01-15 12:31 ` Eli Zaretskii
2024-01-15 13:26 ` Mattias Engdegård
2024-01-18 18:13 ` Mattias Engdegård
2024-01-15 20:01 ` Andy Moreton
2024-01-15 20:21 ` Eli Zaretskii
2024-01-16 21:57 ` Andy Moreton
2024-01-17 3:31 ` Eli Zaretskii
2024-01-18 20:29 ` Andy Moreton
2024-01-19 6:37 ` Eli Zaretskii
2024-01-20 20:20 ` Andy Moreton
2024-01-21 5:11 ` Eli Zaretskii
2024-01-21 13:03 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-22 9:17 ` João Távora
2024-01-22 9:18 ` João Távora
2024-01-23 9:44 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-14 5:25 ` Gerd Möllmann
2024-01-14 14:42 ` Mattias Engdegård
2024-01-21 12:41 ` Stefan Kangas
2024-02-08 9:46 ` Mattias Engdegård
2024-02-08 14:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-08 14:36 ` Gerd Möllmann
2024-02-08 14:42 ` Mattias Engdegård
2024-02-08 15:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-08 17:29 ` Mattias Engdegård
2024-02-08 17:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-12 12:16 ` Mattias Engdegård
2024-02-12 13:36 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-13 9:05 ` Gerd Möllmann
2024-02-13 10:12 ` Mattias Engdegård
2024-02-13 12:12 ` Gerd Möllmann
2024-02-13 12:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-14 12:37 ` Mattias Engdegård
2024-02-14 13:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-14 13:21 ` Mattias Engdegård
2024-02-17 19:50 ` Mattias Engdegård
2024-02-20 10:21 ` Mattias Engdegård
2024-02-20 14:00 ` Eli Zaretskii
2024-02-20 16:11 ` Mattias Engdegård
2024-02-20 17:12 ` Eli Zaretskii
2024-02-21 12:59 ` Eli Zaretskii
2024-02-21 20:13 ` Andrea Corallo
2024-02-23 12:16 ` Mattias Engdegård
2024-02-24 9:45 ` Mattias Engdegård
2024-02-24 10:30 ` Eli Zaretskii
2024-02-24 10:53 ` Mattias Engdegård
2024-02-24 11:03 ` Eli Zaretskii
2024-02-24 17:20 ` Dmitry Gutov
2024-02-24 17:43 ` Mattias Engdegård
2024-02-24 17:48 ` Dmitry Gutov
2024-02-24 17:53 ` Mattias Engdegård
2024-02-24 18:08 ` Eli Zaretskii
2024-02-24 18:31 ` Dmitry Gutov
2024-02-24 17:54 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-24 17:14 ` Dmitry Gutov
2024-02-24 2:46 ` Dmitry Gutov
[not found] ` <20240104155642.6326FC00344@vcs2.savannah.gnu.org>
2024-01-04 18:52 ` scratch/hash-table-perf 3e9e68333ae 16/35: Remove rehash-threshold and rehash-size struct members Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2bf750d-73f0-4aa4-8dd6-11407e20e83e@gutov.dev \
--to=dmitry@gutov.dev \
--cc=68244@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=mattias.engdegard@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.