GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

Message #44 received at 68244 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry <dmitry <at> gutov.dev>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 68244 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#68244: hash-table improvements
Date: Sun, 07 Jan 2024 17:39:06 +0200

[Message part 1 (text/plain, inline)]

On Sun, Jan 7, 2024, at 7:26 AM, Stefan Monnier wrote:
> Side note: I think reasoning won't get us out of this: either we decide
> the choice is important, and then we try and do some
> profiling/benchmarking
That's what I was going to suggest, but concluded that dropping the tallying increments in any of these constructors can lead to risky behavior in degenerate cases.
> The use of memory allocation as a way to decide when to do the next GC
> is just a crude tool anyway, which can often result in bad GC decisions,
> anyway (e.g. typically during long periods of initialization where we
> allocate many objects but don't generate almost any garbage).
Indeed, we have a latency/throughput tradeoff here with the current system, so it would be tempting to reduce the frequency of GCs at least in some cases.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.