all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattias.engdegard@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>,
	68244@debbugs.gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#68244: hash-table improvements
Date: Sat, 6 Jan 2024 12:34:05 +0100	[thread overview]
Message-ID: <B509F736-F46D-494C-A929-DB25D1CF86A6@gmail.com> (raw)
In-Reply-To: <f2bf750d-73f0-4aa4-8dd6-11407e20e83e@gutov.dev>

5 jan. 2024 kl. 16.41 skrev Dmitry Gutov <dmitry@gutov.dev>:

>> 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.

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?






  reply	other threads:[~2024-01-06 11:34 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
2024-01-06 11:34         ` Mattias Engdegård [this message]
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=B509F736-F46D-494C-A929-DB25D1CF86A6@gmail.com \
    --to=mattias.engdegard@gmail.com \
    --cc=68244@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --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.