bzr-grep

Merge lp://qastaging/~gz/bzr-grep/no_match_fast_path into lp://qastaging/bzr-grep

no_match_fast_path
Merge into trunk

Proposed by Martin Packman on 2010-06-06

Status:	Merged
Approved by:	Parth Malwankar on 2010-06-07
Approved revision:	157
Merged at revision:	139
Proposed branch:	lp://qastaging/~gz/bzr-grep/no_match_fast_path
Merge into:	lp://qastaging/bzr-grep
Prerequisite:	lp://qastaging/~gz/bzr-grep/preformat_output
Diff against target:	156 lines (+67/-15) 4 files modified NEWS (+6/-0) __init__.py (+2/-2) grep.py (+53/-13) test_grep.py (+6/-0)
To merge this branch:	bzr merge lp://qastaging/~gz/bzr-grep/no_match_fast_path
Related bugs:	Link a bug report

Reviewer	Review Type	Date Requested	Status
Parth Malwankar		2010-06-06	Approve on 2010-06-07
Review via email: mp+26874@code.qastaging.launchpad.net

Description of the change

Optimisation, avoids splitting the text into a list of lines and testing each one for a match. There are actually a couple of cases where we have avoid this anyway, as explained in the comments, and currently always fall back to splitting into lines after a match is found.

Timings of most interest here will be a big tree with only a few files hit by the pattern.

Revision history for this message

Parth Malwankar (parthm) wrote on 2010-06-07:

This is a really neat optimization. Thanks.
The hot cache numbers for emacs tree working tree search go from 2.39-2.42s to 0.93-0.96s for a pattern thats not found. One we merge in the prerequisite branch we can merge this in. Please add a NEWS entry.

review: Approve

lp://qastaging/~gz/bzr-grep/no_match_fast_path updated on 2010-06-07

158. By Martin Packman on 2010-06-07: Fix previously untested bug with regexp and line numbers introduced by optimisation
159. By Martin Packman on 2010-06-07: Scale back no-match fast path to avoid some behaviour changes with line endings

Revision history for this message

Martin Packman (gz) wrote on 2010-06-07:

Even with the current checks, this branch changes some corner-cases with line-endings. The existing behaviour isn't all that great, but should really decide on what we want the plugin to do and make it consistent.

I've removed a little of the code for the moment, so the first match will happen twice, but the basic speedup should be the same, and the landing risk should be lower.

lp://qastaging/~gz/bzr-grep/no_match_fast_path updated on 2010-06-07