diff options
| author | bors <bors@rust-lang.org> | 2014-05-16 14:46:24 -0700 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2014-05-16 14:46:24 -0700 |
| commit | cea4803d4cf56ded65be6a9e043a6219c661c572 (patch) | |
| tree | 55185a34ed1bbf264c883070e6c67a59a2f8ffc4 /src/rustllvm/PassWrapper.cpp | |
| parent | 5e10686aabb7253e6a6e660e72c7f5de8bbba3de (diff) | |
| parent | 39cb5b13e68b4616a1f1e8dff4fd3f5241e1842a (diff) | |
| download | rust-cea4803d4cf56ded65be6a9e043a6219c661c572.tar.gz rust-cea4803d4cf56ded65be6a9e043a6219c661c572.zip | |
auto merge of #14135 : gereeter/rust/two-way-search, r=brson
This changes the previously naive string searching algorithm to a two-way search like glibc, which should be faster on average while still maintaining worst case linear time complexity. This fixes #14107. Note that I don't think this should be merged yet, as this is the only approach to speeding up search I've tried - it's worth considering options like Boyer-Moore or adding a bad character shift table to this. However, the benchmarks look quite good so far:
test str::bench::bench_contains_bad_naive ... bench: 290 ns/iter (+/- 12) from 1309 ns/iter (+/- 36)
test str::bench::bench_contains_equal ... bench: 479 ns/iter (+/- 10) from 137 ns/iter (+/- 2)
test str::bench::bench_contains_short_long ... bench: 2844 ns/iter (+/- 105) from 5473 ns/iter (+/- 14)
test str::bench::bench_contains_short_short ... bench: 55 ns/iter (+/- 4) from 57 ns/iter (+/- 6)
Except for the case specifically designed to be optimal for the naive case (`bench_contains_equal`), this gets as good or better performance as the previous code.
Diffstat (limited to 'src/rustllvm/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
