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

[Michael Heerdegen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> > my Emacs seems to have become slower independently from gc.  There
> > is still a slow down of searching by a factor of at least 3 or so
> > that doesn't seem to be related to gc.
>
> Have you tried turning on profiling to see what the problem might be?

For el-searches, yes, I did.  But the amounts of time spent were
distributed quite evenly between different things, I could not identify
a culprit.  It looked more like everything got proportionally slower.

> I looked into it a bit, and I think the problem is related to this
> line in el-search--flatten-tree:
>
>         (gc-cons-percentage 0.8)) ;Why is binding it here more
>         effective than binding it more top-level?
>
> That binding is not effective in general, because it causes Emacs to
> do most of its computation with gc-cons-percentage equal to 0.8, but a
> small amount of it with gc-cons-percentage equal to 0.1 (the default
> value).

Yeah.  Funnily enough I had experimented a lot with where to put this
binding.  I also had tried what you suggest in your patch.  What I
currently use looks weird and I don't understand why but in the past it
produced the most efficient result - even more efficient than with a
more durable binding.  Seems this is not true any more.

> This is in an attempt to disable most GC. However, the attempt
> fails in master because when gc-cons-percentage drops to 0.1 Emacs
> does a garbage collection pretty much right away. (In Emacs 26, the
> code lucks out because Emacs happens to not look at gc-cons-percentage
> during the brief time that it is 0.1, so it doesn't GC.)

Ah, ok.

> There may be other places in el-search that would benefit from a
> change similar to the attached patch, but I didn't investigate this.

Yes, I think so.

Question: why didn't it help to switch to hash tables?  My use case is
like this: very frequently I need to collect N (N is variable with an
order of magnitude of roughly 0 < N < 100.000 or so) objects in a
structure and later perform member tests whether a given element is
equal to one of the N.  I used to use a list and `member' to implement
this.  When I use a hash-table that associates the N elements with t
instead, and use gethash as member test, do I produce less garbage?
That would be good but when using this it didn't lower the amount of
time spent in gc.

Thanks,

Michael.