Perfectly reproducible here, marking as NEW. Thanks.

Created attachment 57219 [details] [review]
Alteration to highlighting regexps to improve performance.

I came across this when I was trying to paste 1000-char URLs into an application's input for testing. It takes many many seconds for gnome-terminal to become usable - each time there's a mouse movement to change the highlighting.

http://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@www.lyranthe.org/''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

+ Trace 65154

It seems obvious that this is due to an exponential explosion in the regex possibilities. The problem seemed to like in the "user@domain" highlighting. The section "user@" was highlighted, but the "domain" bit wasn't.

Here is a patch which seems to resolve both the OP's issue and mine.

Would you be so kind to provide your patch in diff -up format?

Actually, it was not that hard to read, and fixed the problem gracefully. Your patch has been committed to CVS HEAD. Thanks a lot!

For what it's worth, I can still reproduce this (as described in the original report) with CVS HEAD.

Created attachment 81226 [details] [review]
Be a little smarter about what we match

Currently we always start mathcing from the start of the screen when looking for something to highlight. This patch starts looking from the beginning of the line in which the pointer is in. I'm not sure this is correct wrt how the beginning of the line is being matched though...

 		/* Repaint the newly-hilited area. */
 		_vte_invalidate_cells(terminal,
-				     0,
-				     terminal->column_count,
+				     terminal->pvt->match_start.column,
+				     terminal->pvt->match_end.column -
+				     terminal->pvt->match_start.column + 1,
 				     terminal->pvt->match_start.row,
 				     terminal->pvt->match_end.row -
 				     terminal->pvt->match_start.row + 1);

This doesn't look right.  The matched area is not necessarily a rectangle, is it?

Urgh, the last two hunks were not meant to be there. Indeed, repainting goes wrong with them.

BTW, it may make sense to remove the match highlighting when we get an LeaveNotify event and simmetrically reshow it on EnterNotify.

Created attachment 81768 [details] [review]
Update Mariano's patch to head

Works well. Though I'm not clear on why it works - the regex matching is an area I've avoided so far ;-)

Created attachment 81898 [details] [review]
Update Mariano's patch to head (regex matching)

[Digression r1639: 2007-02-06  Chris Wilson  <chris@chris-wilson.co.uk>

	And finally as noted on bug 324246#c8 hide the hilite when the mouse
	leaves the terminal (show again when it enters and let motion-notify
	correct it later).

	* src/vte.c: (vte_terminal_enter), (vte_terminal_leave),
	(vte_terminal_realize), (vte_terminal_class_init):
]

For reference, this is one half of the easy part of bug 345344.

Ok, I'm starting to understand what is trying to be achieved here and what the code is doing.

Mariano, your patch is broken in the sense that it does not reset coffset for each regex - as coffset is advanced until a match is found.

I think we should consider multiline regexes to be unsupported and limit the string to the contents of the current row since during simple usage regexec() consumes ~30% of the runtime. Unfortunately that looks like it'll incur a copy as the basic posix regexec does not take a string length. Grrr.

Created attachment 82057 [details] [review]
Perform regex on the single line.

I'm tired but this seems to work.

Created attachment 82058 [details] [review]
Perform regexec() on the single line

Bah apart from the use after free in the g_strndup() of the result. :-(

Can't you temporarily add a '\0' where you want to end the string and restore after the regexec()?

After cleaning up...

r1645: 2007-02-07  Chris Wilson  <chris@chris-wilson.co.uk>

	Bug 345344 – Pattern matching is inefficient
	Bug 324246 – Performance degredation with large numbers of highlighted addresses/URLs

	* src/vte.c: (vte_terminal_match_check_internal):
		Trim the searched string down to the row containing the
		pointer. During a mutt session this drops the time consumed by
		regexec from ~30% to ~2%.
		Note: multi-line regexes are now unsupported!

> Note: multi-line regexes are now unsupported!

Does that mean that long urls that are wrapped are not detected properly now?

Only accidentally ;-)
They should be fine since soft-wrapping does not insert a newline. (However as I forgot to scan forwards to find the next newline...)

Ah, great :) Thanks!

Just to keep everybody happy with those long URLs..

r1646: 2007-02-07  Chris Wilson  <chris@chris-wilson.co.uk>

	* src/vte.c: (vte_terminal_match_check_internal):
		Scan for newlines before and after the current row
		to find the entire line in case of soft-wrapping.