Re: Lost or corrupted `undo-tree' history

[Alexander Shukaev]

On 1/10/20 9:07 AM, Eli Zaretskii wrote:
> > From: Alexander Shukaev <address@hidden>
> > Date: Wed, 8 Jan 2020 23:45:35 +0100
> >
> > I believe the garbage collector can be temporarily disabled
> > by simply wrapping the body of `undo-list-transfer-to-tree' into the
> > following `let' form:
> >
> > (let ((gc-cons-threshold most-positive-fixnum))
> >     ...)
>
> IMO, it would be a very bad mantra for a Lisp package operating on
> this low level to disable GC, because that could cause the user's
> system to run out of memory, and Emacs be killed by the likes of OOM
> killer agents.  Disabling GC is barely a good idea on the
> user-customization level, certainly not in packages such as undo-tree.

Maybe.  I was under impression that for a "short-running" function this 
might be fine to prevent GC from running in-between some Emacs Lisp 
instructions.

Having said that, I agree that disabling GC sometimes may be dangerous 
practice.  I remember how after reading [1], I tried that suggestion for 
minibuffer.  After some time I noticed that I keep running out of 
memory.  What was interesting is the actual test case.  For example, I 
could run some search command which pushes matches into minibuffer, say 
up to 100 000 matches.  As this is happening (and `gc-cons-threshold' is 
`most-positive-fixnum'), I can see memory consumption of Emacs growing 
rapidly say from 500MB up to 8GB at which point I cancel the search and 
exit the minibuffer command.  As a result, `gc-cons-threshold' comes 
back to the default value and garbage collecting starts immediately. 
However, the memory consumption of Emacs does not fall back to 500MB, 
but rather goes down to only e.g. 6GB, which afterwards are never ever 
reclaimed.  If I repeat the test, the memory consumption would 
immediately continue to grow off 6GB further as if those 6GB are not 
reused and are somehow stuck holding something that cannot be reclaimed 
anymore.  Hence, you can see that if I way same amount of time, the 
memory consumption would go to around 14GB.  This is how one can quickly 
run out of memory as if there would be some memory leaks related to GC.

Now, I have no experience to say whether lower (e.g. default) values of 
`gc-cons-threshold' don't trigger memory leaks or they simply go 
unnoticed because the memory consumption grows very slowly.  Since, 
theoretically, GC memory leak if present should be there regardless of 
`gc-cons-threshold'.  Thoughts?

Nevertheless, the second suggestion (for speeding up initialization 
code) from [1], IMO, is a good example of temporarily blowing 
`gc-cons-threshold' which I still use.

[1] 
https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/