Introduce simple string matcher #2433
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
urso
added
in progress
urso
force-pushed
the
enh/string-matcher
branch
from
79a0120
to
ae31a99
Compare
|
Updated matcher with support for handling dates (only numeric) at beginning of logs and alternative prefixes. Updated benchmarks: |
urso
changed the title
urso
added
review
and removed
in progress
|
@urso |
ruflin
approved these changes
Jan 11, 2017
| logContentLevel, | ||
| } | ||
|
|
||
| var mixedContent = makeContent("mixed", `Lorem ipsum dolor sit amet, |
There was a problem hiding this comment.
Very nice to see this extensive test suite. I kind of expect that we will hit some cases we haven't thought of but this will be easily fixible by just adding a test with the exception and find the issue.
| { | ||
| `^\s*$`, | ||
| typeOf((*emptyWhiteStringMatcher)(nil)), | ||
| // []string{"", " ", "\t"}, |
| @@ -0,0 +1,204 @@ | |||
| package match | |||
There was a problem hiding this comment.
There are kind of two solutions here:
- We fix it automatically for the user what this code is doing
- We log a warning to the that his regexp is not optimal and that he could optimize it when doing x
- Doing a combination of both
I would opt for version 3. But will any user ever have a look at it an optimize the regexp query if we tell him it is not optimal? Main thing about doing 1 is that this could introduce potential errors. Means the regexp we use internally is not the regexp someone has in the config file. So it would be good to at least have some debug message with the now used regexp.
Hm... my editor is using |
|
Added alternative literals use case (e.g. |
andrewkroh
approved these changes
Jan 11, 2017
|
@urso do you prefer squash and merge or to do rebase yourself? |
|
let me rebase first and get a proper commit message. |
Provide match.Matcher and match.ExactMatcher using regular expressions for matching use-case only. The matchers compile a regular expression into a Matcher, which only provides the Match functionality. This gives us a chance to optimize/replace some common cases used for matching: - replace capture-groups by non-capturing groups - remove leading/trailing `.*` expressions (Match already searches for sub-string matching the regex) - replace simple literal searches with `==` and `strings.Contains` and `strings.startsWith` - replace regex for alternative literals (e.g. `DEBUG|INFO|ERROR`) with strings.Contains over set of literals - optimized empty-lines checks If input regular expression can not be matched to a simple case, regexp.Regexp will be used. The `ExactMatcher` will embedd `<regex>` into `^<regex>$` by default. Note: Matcher does currently not split simple cases. e.g. `abc.*def` or `abc.def` will still fallback to regexp.Regexp.
urso
force-pushed
the
enh/string-matcher
branch
from
f7f6b7c
to
c683077
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Match further optimizes special regular expressions, trying to replace
special regular patterns with more performance string searches.
benchmark results:
run 1:
run 2:
In
BenchmarkBeginningDatebenchmark the regular expression can not be optimized (yet?), resulting inRegexandMatchtests, both executing full regular expression.