Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
tweak cutoffs
  • Loading branch information
sweeneyde committed Jul 11, 2021
commit 6be0c32379205935cb907182c33b6f651b2eaf76
4 changes: 2 additions & 2 deletions Objects/stringlib/fastsearch.h
Original file line number Diff line number Diff line change
Expand Up @@ -748,10 +748,10 @@ FASTSEARCH(const STRINGLIB_CHAR* s, Py_ssize_t n,
}

if (mode != FAST_RSEARCH) {
if (n < 2000 || (m < 100 && n < 30000) || m < 6) {
if (n < 3000 || (m < 100 && n < 30000) || m < 6) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did you come about those numbers?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll consolidate the benchmarks I used and post them here. But this is a chart comparing the default implementation to the existing two-way implementation. The equivalent chart for this implementation is similar, and I'm trying to essentially to cut out the green bits of that image.

For now though, the differences this PR makes have some benchmarks here

return STRINGLIB(default_find)(s, n, p, m, maxcount, mode);
}
else if (5 * m < n) {
else if (6 * m < n) {
/* For larger problems where the needle isn't a huge
percentage of the size of the haystack, the relatively
expensive O(m) startup cost of the two-way algorithm
Expand Down