This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Dennis Sweeney, Zeturic, ammar2, corona10, josh.r, pmpp, serhiy.storchaka, tim.peters, vstinner
Date 2020-10-13.21:30:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1602624639.18.0.877103319497.issue41972@roundup.psfhosted.org>
In-reply-to
Content
> For a bunch of cases it's slower, for some others it's faster.

I have scant real idea what you're doing, but in the output you showed 4 output lines are labelled "slower" but 18 are labelled "faster".

What you wrote just above appears to say the reverse (I'd call 18 "a bunch" compared to 4 "some others").

Could please state plainly which of {status quo, PR} is faster on an output line labelled "faster"?

My a priori guess was that the PR had the highest chance of being slower when the needle is short and is found in the haystack early on. Then preprocessing time accounts for a relatively higher percentage of the total time taken, and the PR's preprocessing is more expensive than the status quo's.

The alphabet size here is small (just 26 possible letters, from `ascii_uppercase`), so it's quite likely that a short needle _will_ be found early on in a long haystack.
History
Date User Action Args
2020-10-13 21:30:39tim.peterssetrecipients: + tim.peters, vstinner, pmpp, serhiy.storchaka, josh.r, ammar2, corona10, Dennis Sweeney, Zeturic
2020-10-13 21:30:39tim.peterssetmessageid: <1602624639.18.0.877103319497.issue41972@roundup.psfhosted.org>
2020-10-13 21:30:39tim.peterslinkissue41972 messages
2020-10-13 21:30:39tim.peterscreate