Re^2: Matching Regular expression at EOF

Wouldn't anchoring the pattern at the end of the string with \z or one of its ilk (e.g., m{ pat \z }xms) tend to be faster since the .* doesn't need to 'consume' virtually the whole file? Or is this the kind of thing that just gets optimized away?

Update: Contrary to krish28's clarification in Re^2: Matching Regular expression at EOF, this question assumes the entire file is held in a single string. But the question still stands.

Comment on Re^2: Matching Regular expression at EOF Select or Download Code

Replies are listed 'Best First'.
Re^3: Matching Regular expression at EOF by ikegami (Patriarch) on Feb 20, 2010 at 19:42 UTC
He wants the last instance of the pattern in the file. It might not at the very end of the file. As for speed, `(?s:.*)` jumps right to the end of the file. `(?s:.)` matches anything, so no check needs to be made (and none is done).	[reply] [d/l] [select]
Re^3: Matching Regular expression at EOF by JavaFan (Canon) on Feb 22, 2010 at 16:52 UTC
Anchoring at the end of the string only matches if there's an actual match at the end of the string. But the last match doesn't imply it's at the end of the string. For instance, in the string below, there are two matches for `/a.b/`, on of them the last one, but none for `/a.b\z/`. `"123 a!b 456 a?b 789"` [download]	[reply] [d/l] [select]
Re^4: Matching Regular expression at EOF by AnomalousMonk (Archbishop) on Feb 22, 2010 at 21:53 UTC
In my original persual of the OP, I missed the phrase "last occurence" [sic] and was beguiled by the phrases "Matching ... at EOF" and "match ... at the very end of the input file". Starting from my assumption that the entire file had been slurped into a string, I strayed into a consideration of `\z` et al. I now recognize my error.	[reply] [d/l]