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

[Dmitry Gutov]

On 03.03.2021 00:14, Theodor Thornhill via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:
> 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?

You probably mean to short-circuit as soon as you reach the target 
column (there might be multiple matches within those 500 chars), 
skipping the rest of the matches on the same line.

Sounds worth a try.

Another approach would be to truncate the line sometime earlier, like:

diff --git a/lisp/progmodes/xref.el b/lisp/progmodes/xref.el
index 18fdd963fb..63a17a8521 100644
--- a/lisp/progmodes/xref.el
+++ b/lisp/progmodes/xref.el
@@ -1531,7 +1531,10 @@ xref-matches-in-files
       (while (re-search-forward grep-re nil t)
         (push (list (string-to-number (match-string line-group))
                     (match-string file-group)
-                    (buffer-substring-no-properties (point) 
(line-end-position)))
+                    (buffer-substring-no-properties (point)
+                                                    (min
+                                                     (+ (point) 500)
+                                                     (line-end-position))))
               hits)))
     (xref--convert-hits (nreverse hits) regexp)))


...of course, ideally we would keep all contents of the line somewhere 
in memory and truncate with (setq truncate-line t). But IIRC Juri said 
this didn't give us as much of a speedup as we'd want.

Another question: how many hits do you usually have in that huge 
one-line file? If it's more than 2-3, it might be that our current 
algorithm which creates "match objects" will duplicate this string 
unnecessarily N times (which is the number of hits), in 
xref--collect-matches-1, to then cut it up and merge into one line again 
when printing the buffer. In which case the patch above should also show 
a healthy improvement, but we could figure out something better instead.

Anyway, please benchmark your "earlier short-circuit" approach and then 
the above patch too.