Rework of FindSubstring using iterator instead

[fflorent]

Use an iterator of Memchr for FindSubstring, accordingly to the discussion in #507.

Don't hesitate to bikeshed. Also I won't be offended if you don't feel that's worthy :).

Florent

[coveralls]

Coverage decreased (-0.009%) to 88.067% when pulling 73021eb on fflorent:memchr_change_proposal into 460041a on Geal:master.

[coveralls]

Coverage decreased (-0.009%) to 88.067% when pulling 73021eb on fflorent:memchr_change_proposal into 460041a on Geal:master.

[fflorent]

@Hywan In order to check how fast is this implementation compared to the previous one, do you still have the bench test for this #507 (comment)?

Thanks in advance :)

[Hywan]

@fflorent No I don't, sorry :-(.

[Hywan]

Add +1 directly to the definition of max.

[Hywan]

And then remove +1 here.

[fflorent]

Done, thanks!

[fflorent]

I have committed a banchmark in specific.rs for take_until_and_consume.

Here are the results:

-- before
running 1 test
test take_until_and_consume_bench ... bench:         272 ns/iter (+/- 6)

-- after
running 1 test
test take_until_and_consume_bench ... bench:         310 ns/iter (+/- 3)

So… not really good I would say. There might be tricks to catch up the previous performance, I am doing tests.

[coveralls]

Coverage increased (+0.04%) to 88.118% when pulling 6d00f95 on fflorent:memchr_change_proposal into 460041a on Geal:master.

[fflorent]

A quick look didn't give me any hint on how to keep the optimization. I guess such a gap of performance between the previous solution and this proposal excludes the latter.

May I close the PR? Or do you (@Hywan, @Geal) have some ideas on your side?

[coveralls]

Coverage increased (+0.04%) to 88.118% when pulling e004a52 on fflorent:memchr_change_proposal into 460041a on Geal:master.

[Hywan]

Using an iterator would be better for safety and readiness for sure. However I am not able to obtain better performances with the iterator API.

It's up to @Geal to decide :-).