Optimize core::str::Lines::count

[thomcc]

s.lines().count()+1 is somewhat common as a way to find the line number given a byte position, so it'd be nice if it were faster.

This just generalizes the SWAR-optimized char counting code so that it can be used for SWAR-optimized line counting, so it's actually not very complex of a PR.

TODO

• benchmarks
• adjust comments
• more tests

Benchmarks

case00_libcore is the new version, and case01_fold_increment is the previous implementation (the default impl of Iterator::count() is a fold that increments

    str::line_count::all_newlines_32kib::case00_libcore           4.35µs/iter  +/- 11.00ns
    str::line_count::all_newlines_32kib::case01_fold_increment  779.99µs/iter   +/- 8.43µs
    str::line_count::all_newlines_4kib::case00_libcore          562.00ns/iter   +/- 5.00ns
    str::line_count::all_newlines_4kib::case01_fold_increment    97.81µs/iter   +/- 1.48µs
    str::line_count::all_newlines_64b::case00_libcore            21.00ns/iter   +/- 0.00ns
    str::line_count::all_newlines_64b::case01_fold_increment      1.49µs/iter  +/- 32.00ns

    str::line_count::en_huge::case00_libcore                     45.58µs/iter +/- 122.00ns
    str::line_count::en_huge::case01_fold_increment             167.62µs/iter +/- 609.00ns
    str::line_count::en_large::case00_libcore                   734.00ns/iter   +/- 6.00ns
    str::line_count::en_large::case01_fold_increment              2.62µs/iter   +/- 9.00ns
    str::line_count::en_medium::case00_libcore                  100.00ns/iter   +/- 0.00ns
    str::line_count::en_medium::case01_fold_increment           347.00ns/iter   +/- 0.00ns
    str::line_count::en_small::case00_libcore                    18.00ns/iter   +/- 1.00ns
    str::line_count::en_small::case01_fold_increment             60.00ns/iter   +/- 2.00ns
    str::line_count::en_tiny::case00_libcore                      6.00ns/iter   +/- 0.00ns
    str::line_count::en_tiny::case01_fold_increment              60.00ns/iter   +/- 0.00ns

    str::line_count::zh_huge::case00_libcore                     40.63µs/iter  +/- 85.00ns
    str::line_count::zh_huge::case01_fold_increment             205.10µs/iter   +/- 1.62µs
    str::line_count::zh_large::case00_libcore                   655.00ns/iter   +/- 1.00ns
    str::line_count::zh_large::case01_fold_increment              3.21µs/iter  +/- 21.00ns
    str::line_count::zh_medium::case00_libcore                   92.00ns/iter   +/- 0.00ns
    str::line_count::zh_medium::case01_fold_increment           420.00ns/iter   +/- 2.00ns
    str::line_count::zh_small::case00_libcore                    20.00ns/iter   +/- 1.00ns
    str::line_count::zh_small::case01_fold_increment             63.00ns/iter   +/- 1.00ns
    str::line_count::zh_tiny::case00_libcore                      6.00ns/iter   +/- 0.00ns
    str::line_count::zh_tiny::case01_fold_increment              21.00ns/iter   +/- 0.00ns

This is a speedup of around 2x-4x most of the time, but for some highly unrealistic scenarios (32KiB of newlines) it's up to almost 200x faster (because the time taken by the version in this PR is not dependent on the number of newlines in the input, but the old version is slower the more newlines are present). It's also much faster for small inputs, especially if they have newlines (10x faster for en_tiny).

Real world cases will vary, don't read too much into these, I would expect 2x-4x speedup in general, since that's what it gets on the most realistic examples.

Obviously a SIMD impl will beat this, but users who are really bottlenecked on this operation should probably just reach for crates.io (even if we provided a SIMD version, libcore can't use runtime CPU feature detection so they'd still be better off with something from crates.io).

[rustbot]

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[thomcc]

Clearing assignee cuz it's a draft still.

[thomcc]

I've updated the PR description to contain benchmarks. This PR needs more tests tho, almost missed that I got the logic wrong for going from newline count to line count.

[thomcc]

i don't have time/energy to poke at this right now (maybe over the weekend)... but it seems it is used in the compiler so curiosity is getting the better of me.

@bors try @rust-timer queue

[bors]

⌛ Trying commit ef27373 with merge eb24f76...

[bors]

☀️ Try build successful - checks-actions
Build commit: eb24f76 (eb24f76fec39eaf9264ad15cf44aed176968e12e)

[bors]

☀️ Try build successful - checks-actions
Build commit: eb24f76 (eb24f76fec39eaf9264ad15cf44aed176968e12e)

[rust-timer]

Finished benchmarking commit (eb24f76): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.3%, 0.4%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.4%	[-0.7%, -0.2%]	2
All ❌✅ (primary)	0.3%	[-0.2%, 0.4%]	6

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	7.8%	[0.2%, 15.3%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-2.3%, -1.3%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[-2.3%, 15.3%]	5

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-5.4%, -2.3%]	17
All ❌✅ (primary)	-	-	0

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.6%]	10
Regressions ❌ (secondary)	0.8%	[0.2%, 1.4%]	2
Improvements ✅ (primary)	-0.0%	[-0.2%, -0.0%]	18
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	18
All ❌✅ (primary)	0.0%	[-0.2%, 0.6%]	28

Bootstrap: 676.389s -> 679.092s (0.40%)
Artifact size: 316.13 MiB -> 316.09 MiB (-0.01%)