bug#46859: 28.0.50; [PATCH]: Add option to truncate long lines in xref.el

[Theodor Thornhill via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Hi, Dmitry,

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Theodor,
>
> On 02.03.2021 23:13, Theodor Thornhill via Bug reports for GNU Emacs, 
> the Swiss army knife of text editors wrote:
>> Yeah, maybe.  However, without benchmarking, it is quite clear that
>> adding your option is faster than my patch, since ripgrep has to search
>> the whole minified file.  I assume it short circuits, so that results
>> are delivered quicker to emacs.  Maybe this bug can be closed.
>
> Could you try benchmarking both approaches?
>
Ok, so here are some numbers:

;; With nothing
(benchmark-run 10 (project-find-regexp "UrlChange")) ;; (11.748253 14 0.23526199999999997)

;; With -M 500
(benchmark-run 10 (project-find-regexp "UrlChange")) ;; (0.293626 0 0.0)

;; My patch
(benchmark-run 10 (project-find-regexp "UrlChange")) ;; (1.230833 8 0.13783999999999996)

> If the performance improvement from yours is at all comparable with 
> Juri's, I'm inclined to prefer that direction for reasons described in 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44983#71.
>

So, now it looks like my patch is an improvement, but not as much as
limiting from ripgrep.  I think that is because in my version, we still
loop over the whole file, we just delete the contents so that we always
show 500 columns.  I'm interested in seeing if I could gain some more
performance by short circuiting after the first iteration of a match on
the same line.  In my test scenario there are a lot of matches on the
same huge line.  What do you think?

--
Theo