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

[Paul Eggert <eggert@cs.ucla.edu>]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

On 9/14/19 2:57 AM, Eli Zaretskii wrote:
> If we cannot give any specifics, I think at least telling users to
> re-tune their GC tricks would help.

I installed the attached to try to do that.

[-- Attachment #2: 0001-Improve-doc-of-GC-thresholds.patch --]
[-- Type: text/x-patch, Size: 2794 bytes --]

From 1acc0cc9aaf25c808a60cf09cf8a4d1c653c3aa9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 14 Sep 2019 10:53:24 -0700
Subject: [PATCH] Improve doc of GC thresholds

* doc/lispref/internals.texi (Garbage Collection), etc/NEWS:
Warn that control over GC is only approximate.
---
 doc/lispref/internals.texi | 13 ++++++++++---
 etc/NEWS                   |  7 +++++++
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi
index f85c266ede..c52999e1cd 100644
--- a/doc/lispref/internals.texi
+++ b/doc/lispref/internals.texi
@@ -533,9 +533,6 @@ Garbage Collection
 trigger another garbage collection.  You can use the result returned by
 @code{garbage-collect} to get an information about size of the particular
 object type; space allocated to the contents of buffers does not count.
-Note that the subsequent garbage collection does not happen immediately
-when the threshold is exhausted, but only the next time the Lisp interpreter
-is called.
 
 The initial threshold value is @code{GC_DEFAULT_THRESHOLD}, defined in
 @file{alloc.c}.  Since it's defined in @code{word_size} units, the value
@@ -562,6 +559,16 @@ Garbage Collection
 proportion.
 @end defopt
 
+  Control over the garbage collector via @code{gc-cons-threshold} and
+@code{gc-cons-percentage} is only approximate.  Although Emacs checks
+for threshold exhaustion regularly, for efficiency reasons it does not
+do so immediately after every change to the heap or to
+@code{gc-cons-threshold} or @code{gc-cons-percentage}, so exhausting
+the threshold does not immediately trigger garbage collection.  Also,
+for efficency in threshold calculations Emacs approximates the heap
+size, which counts the bytes used by currently-accessible objects in
+the heap.
+
   The value returned by @code{garbage-collect} describes the amount of
 memory used by Lisp data, broken down by data type.  By contrast, the
 function @code{memory-limit} provides information on the total amount of
diff --git a/etc/NEWS b/etc/NEWS
index 94c98a7ebe..252c6bf9b9 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2429,6 +2429,13 @@ remote systems, which support this check.
 +++
 ** 'memory-limit' now returns a better estimate of memory consumption.
 
++++
+** When interpreting 'gc-cons-percentage', Emacs now estimates the
+heap size more often and (we hope) more accurately.  E.g., formerly
+(progn (let ((gc-cons-percentage 0.8)) BODY1) BODY2) continued to use
+the 0.8 value during BODY2 until the next garbage collection, but that
+is no longer true.  Applications may need to re-tune their GC tricks.
+
 +++
 ** New macro 'combine-change-calls' arranges to call the change hooks
 ('before-change-functions' and 'after-change-functions') just once
-- 
2.17.1