@guy038 said in Removing all lines that don't contain multiple texts in multiple files:
In order to identify nice regex S/R, we should, globally, take execution time and number of steps in account, more often !
@guy038, I commend you for your in depth study of the effect of lazy and greedy quantifiers on execution times. It’s good to know that it did back up my theory. I suppose I hadn’t; until this time; actually spent much time in considering the effect, but actually I had subconsciously been applying the theory anyway.
When you say “Note the irony of such a sentence: we need a lazy quantifier for faster execution ;-))” I think that it is actually quite self explanatory.
I suppose I’ve thought that a greedy quantifier must still process the line 1 character at a time until the end of the line is reached (unless there is some magical way it can grab instantly ALL characters on a line), just doing an end of line test (I’m only talking (?-s) option). Then it must process 1 character at a time in reverse for the actual regex match it is looking for. The lazy quantifier JUST processes 1 character at a time proceeding across the line until the match is found.
It’s possible (as I stated earlier) that the (.*) might be an extremely fast process, but even if the match string is evenly positioned across a line there (to my mind) would still be some processing overhead for a greedy quantifier with respect to a lazy one. At this point I’m actually being contrary to a previous statement I made:
“As mine will “avoid” a line that DOES have the match (and therefore stays) in 7 character checks, your greedy regex will take more character checks on a long line, and less on a short line.”
I now think that a greedy quantifier will ALWAYS make more tests (steps) in processing the same line, regardless of whether there is a match or not.
And @Alan-Kilborn , indeed you are right to some degree, all this doesn’t matter for most OPs. But I only have to turn to the many topics on which many of the seasoned members have contributed ever increasing tighter code as alternative answers to OP questions. One might show an answer, then another picks that regex apart, see what makes it tick and realises there are some efficiencies to be made and presents an updated version. Now with @guy038’s tests we can see yet another tool we can add to our toolbox, the consideration that a lazy quantifier isn’t so lazy after all.
Cheers
Terry
PS and sorry to you @guy038 for your problems with XP not being able to use the regex101 site. I will have to say though the old addage “flogging a dead horse” comes to mind.
https://en.wikipedia.org/wiki/Flogging_a_dead_horse