chore: Improve containsLower performance using quick rejection

[cyriltovena]

This pull request includes improvements to the containsLower function in pkg/logql/log/filter.go for better performance and adds benchmark tests to ensure the changes are effective. The key changes include optimizing the case-insensitive substring search and introducing comprehensive benchmark tests.

Optimizations to containsLower function:

• pkg/logql/log/filter.go: Optimized the containsLower function by implementing a more efficient search algorithm that first locates the potential starting byte of the substring and then verifies the rest of the substring with both fast ASCII and slower Unicode comparisons.

Addition of benchmark tests:

• pkg/logql/log/filter_test.go: Added a new benchmark function BenchmarkContainsLower with various test cases to evaluate the performance of the containsLower function under different scenarios, including short and long lines, matches and non-matches, and lines with Unicode characters.

Result:

benchstat before.txt before2.txt
name                                             old time/op    new time/op    delta
name                                             old time/op    new time/op    delta
ContainsLower/short_line_no_match-16               45.6ns ± 2%    17.6ns ± 5%  -61.28%  (p=0.008 n=5+5)
ContainsLower/short_line_with_match-16             29.3ns ±12%    27.6ns ± 9%     ~     (p=0.222 n=5+5)
ContainsLower/long_line_no_match-16                 486ns ± 5%     247ns ± 2%  -49.14%  (p=0.008 n=5+5)
ContainsLower/long_line_match_start-16             7.70ns ± 3%    8.99ns ± 5%  +16.82%  (p=0.008 n=5+5)
ContainsLower/long_line_match_middle-16             205ns ± 3%     103ns ± 7%  -49.89%  (p=0.008 n=5+5)
ContainsLower/long_line_match_end-16                469ns ± 2%     299ns ±36%  -36.18%  (p=0.008 n=5+5)
ContainsLower/short_unicode_line_no_match-16        203ns ± 4%      46ns ± 9%  -77.27%  (p=0.008 n=5+5)
ContainsLower/short_unicode_line_with_match-16     69.0ns ± 1%    42.1ns ±17%  -38.99%  (p=0.008 n=5+5)
ContainsLower/long_unicode_line_no_match-16        2.03µs ± 1%    0.22µs ± 1%  -89.14%  (p=0.016 n=5+4)
ContainsLower/long_unicode_line_match_start-16      724ns ± 2%     290ns ± 0%  -59.89%  (p=0.016 n=5+4)
ContainsLower/long_unicode_line_match_middle-16     805ns ± 0%      86ns ± 8%  -89.36%  (p=0.016 n=4+5)
ContainsLower/long_unicode_line_match_end-16       3.70µs ± 1%    0.39µs ±11%  -89.35%  (p=0.008 n=5+5)

*What this PR does / why we need it:

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[cyriltovena]

Sounds like test failure so will need to check

[jeschkies]

Interesting I've always thought Loki was using strings.Index but I guess one cannot ignore character casing there.

Anyhow, during my work on a SIMD substring search I've found that the underlying Rabin-Karp algorithm is soo much faster. I'm curious if it could be adapted to be case-insensitive 🤷

[cyriltovena]

We don't for case sensitive yes. What do you think of the PR though that would help me to get a review.