bug#37321: 27.0.50; Excessive gc in a use case (el-search)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: eggert@cs.ucla.edu,  37321@debbugs.gnu.org
> Date: Tue, 08 Oct 2019 13:12:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Start with 4 times the default.  If that's not enough, double the
> > value until you are satisfied, and tell what was the final value.
> 
> I leave it to you to interpret the result (can we expect that other use
> cases have a similar optimum?):
> [...]
> 61.893515s (14.088496s in 63 GCs)
> 
> 
> (setq gc-cons-threshold (* 800000 128))
> 
> 56.277259s (8.122554s in 32 GCs)
> 
> (setq gc-cons-threshold (* 800000 256))
> 
> 55.173263s (6.067774s in 17 GCs)
> 
> (setq gc-cons-threshold (* 800000 512))
> 
> 56.116736s (8.825274s in 9 GCs)
> 
> (setq gc-cons-threshold (* 800000 1024))
> 
> 70.832969s (19.474471s in 5 GCs)

IMO, this suggests that your code produces a lot of garbage, so it is
not a good basis for setting the default values.  I would be OK with
bumping up the default gc-cons-threshold 8-fold, or even 16-fold, but
increasing it by a factor of 256 is too much, IMO: it would mean we
only GC after consing ~200MB of data, which is about half the heap
size of my current Emacs session, which has been up and running for 28
days, and has 360 live buffers.

Thanks.