Posted here about a month ago: <a href="https://news.ycombinator.com/item?id=43333946">https://news.ycombinator.com/item?id=43333946</a>
The fact that even in the test example it took ripgrep 0.115 s with 97% CPU usage vs Krep's 0.106 s with 328% CPU usage is a testament of why ripgrep is still preferable. Such a huge tradeoff in resource consumption for such a small speed gain is hard to justify
There's a few issues with the Horspool implementation.<p>To obtain non case sensitive searching, you set the shift in the bad char table for both the upper and lower case variants. That's fine. But when you come to do the search, you ignore this and only look up the lower case version if it's non case sensitive. This is unnecessary - the valid shifts for both cases are already in the table, since you put them there. So you can avoid doing a lookup on the lower table.<p>I think you also only ever shift by one if you get a full match, but this is also unnecessary. You can shift by whatever the last char bad char shift is and you won't miss any patterns, even if they can overlap.<p>Finally, you have a test to see if the shift is zero, and to set it to one if it is. You should never get a shift of zero from the bad char table (you don't process the last char of the pattern when creating the bad char table, so there is never a distance of zero from the end).
I have just released version 1.1.0 which should fix the problems reported by users.<p><a href="https://github.com/davidesantangelo/krep/releases/tag/v1.1.0">https://github.com/davidesantangelo/krep/releases/tag/v1.1.0</a>