Perl does a pretty good job at optimizing such things: $ time perl -Mre=debug -e '(" " x 100000000 . "X") =~ /\s+$/ && print "MATCH"' Compiling REx "\s

Perl does a pretty good job at optimizing such things: $ time perl -Mre=debug -e '(" " x 100000000 . "X") =~ /\s+$/ && print "MATCH"' Compiling REx "\s+$" Final program: 1: PLUS (3) 2: POSIXD[\s] (0) 3: EOL (4) 4: END (0) floating ""$ at 1..9223372036854775807 (checking floating) stclass POSIXD[\s] plus minlen 1 Matching REx "\s+$" against " "... Intuit: trying to determine minimum start position... Found floating substr ""$ at offset 100000001... (multiline anchor test skipped) looking for class: start_shift: 1 check_at: 100000001 rx_origin: 0 endpos: 100000001 Does not contradict STCLASS... Intuit: Successfully guessed: match at offset 0 Matching stclass POSIXD[\s] against " "... (100000001 bytes) 0 <> < > | 1:PLUS(3) POSIXD[\s] can match 100000000 times out of 2147483647... 100000000 < > <X> | 3: EOL(4) failed... failed... Contradicts stclass... [regexec_flags] Match failed Freeing REx: "\s+$" real 0m0.427s user 0m0.312s sys 0m0.076s Basically, the regex egine sees a $ anchor, moves to the end of the string, and finds that it can't ever match there. It makes it quite hard to accidentally trigger such bad regex behavior. See for example https://perlgeek.de/blog-en/perl-tips/in-search-of-an-exponetial-regexp.html https://perlgeek.de/blog-en/perl-tips/in-search-of-an-expone... (disclaimer: my own blog)