GNOME Bugzilla – Bug 345344
Pattern matching is inefficient
Last modified: 2007-02-07 09:52:13 UTC
I've been experimenting with different regexes for vte_terminal_match_add and found that some combinations of screen contents and complex regexes cause drastic CPU usage and slowdown. As far as I can tell from browsing the source, every time the pointer is moved vte searches for pattern matches over the entire visible area then checks which are under the pointer. Couldn't it cache the matches until the visible contents change? Another possible strategy would be to assume that multiline matches aren't necessary and search backwards from the pointer position to the nearest line break and start the search from there, ending with the first match.
Yeah, it should only match the current line (which may span several rows.)
Well I did once try to use multiline matching to repair long URLs mangled by slrn (it inserts a space at the start of wrapped lines, I can't see how to disable that) but the pattern was so complicated that was one of the things that gave me severe performance problems so I agree, it's probably best to avoid multiline matches on the whole.
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!