Minor optimisation of the string operations

[nagisa]

The interesting benchmarks are

(<100% → better than original )	Delta	Original ns/i	This Patch ns/i
str::contains_bang_char::long_lorem_ipsum	24.98%	5565	1390
str::contains_bang_char::short_ascii	27.78%	144	40
str::contains_bang_char::short_mixed	33.33%	120	40
str::contains_bang_char::short_pile_of_poo	59.42%	69	41
str::ends_with_ascii_char::long_lorem_ipsum	45.26%	5457	2470
str::ends_with_ascii_char::short_ascii	45.01%	5486	2469
str::ends_with_ascii_char::short_mixed	46.31%	5452	2525
str::ends_with_ascii_char::short_pile_of_poo	45.34%	5443	2468
str::ends_with_unichar::long_lorem_ipsum	45.94%	5466	2511
str::ends_with_unichar::short_ascii	46.06%	5456	2513
str::ends_with_unichar::short_mixed	45.50%	5486	2496
str::ends_with_unichar::short_pile_of_poo	45.65%	5448	2487
str::find_underscore_char::long_lorem_ipsum	62.21%	5567	3463
str::find_underscore_char::short_ascii	66.44%	146	97
str::find_underscore_char::short_mixed	76.23%	122	93
str::find_underscore_str::short_pile_of_poo	47.62%	252	120
str::find_zzz_char::long_lorem_ipsum	62.17%	5569	3462
str::find_zzz_char::short_ascii	66.67%	147	98
str::find_zzz_char::short_mixed	75.41%	122	92
str::find_zzz_str::long_lorem_ipsum	72.86%	925	674
str::rfind_underscore_char::long_lorem_ipsum	34.19%	7128	2437
str::rfind_underscore_char::short_ascii	37.31%	193	72
str::rfind_underscore_char::short_mixed	41.42%	169	70
str::rfind_underscore_char::short_pile_of_poo	50.51%	99	50
str::rfind_zzz_char::long_lorem_ipsum	34.20%	7129	2438
str::rfind_zzz_char::short_ascii	37.11%	194	72
str::rfind_zzz_char::short_mixed	40.94%	171	70
str::rfind_zzz_char::short_pile_of_poo	54.81%	104	57
str::trim_right_ascii_char::short_mixed	110.42%	48	53
string::bench_from	117.24%	58	68
string::bench_from_str	117.24%	58	68
string::bench_push_str	111.11%	54	60
string::bench_to_string	112.07%	58	65
string::from_utf8_lossy_100_invalid	111.31%	1529	1702

[cbreeden]

I'm having a hard time finding where any of your changes impact string::bench_[from|from_str|push_str|to_string].

[arielb1]

r? @sfackler

[sfackler]

How much do the #[inline]s matter here in comparison to the changes to the Pattern impl for char?

[nagisa]

I did notice LLVM refusing to inline Pattern instantiations, resulting in significantly worse code. I guess inlines on the non Pattern methods could be removed.

[sfackler]

It'd be nice to cut it down to the minimum set of changes required to get the perf improvements we're looking for, yeah.

[nagisa]

Removing the unnecessary inline annotations removed some of the larger regressions as well.

[sfackler]

@bors r+

[bors]

📌 Commit 41debc3 has been approved by sfackler

[lilianmoraru]

Observed this in TWIR...
Not sure the inline is very good. In artificial benchmarks it will look good most of the time but in real code it might blow the instruction cache(bring these functions in but throw the other ones and then when you get back to the other ones, you have to throw these... imagine some kind of loop).
Of course "might" does not mean that it will. That's why in the C++ world it is usually recommended to let the compiler/optimizer analyze the code an decide.

[cbreeden]

That's why in the C++ world it is usually recommended to let the compiler/optimizer analyze the code an decide.

Using #[inline] doesn't force inline, it just (now I'm really going to butcher this), exports the object file to give LLVM the chance to inline it (though I'm sure what I said isn't accurate). There is an #[inline(always)], but that's not what's being done here.

[lilianmoraru]

I call it a suggestion to the compiler to inline.
From what I've seen, it usually tries to inline, unless the function is too complicated.