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

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> > in a way that gc doesn't lower the speed that much
>
> AFAIK, the latter can only be done by changing your algorithms to
> produce less garbage.

I tried to find out what code produces the most garbage.  It turned out
that ca. 50% of garbage was generated by code that prevents infinite
recursion when recursing into nested structures.  I use hash tables to
collect visited objects, and the hash tables cause the garbage.  I tried
to reuse hash tables and clear them after each use, but this makes the
code much slower than what I win from gc.

But 99,9% of el-searched code isn't cyclic, so the effort is for nothing
most of the time.  Is there an efficient way to find out if a given
object is cyclic?

For now I try with this:

(lambda ()
  (save-excursion)
  (goto-char (point-min))
  (search-forward-regexp "#[0-9+]=[^\"]" nil t))

(all treated objects are read from a buffer, so I can inspect the
contents) and get good results but it feels a bit hackish.


Thanks,

Michael.