Speed up Vec::clear().

[nnethercote]

Currently it just calls truncate(0). truncate() is (a) not marked as
#[inline], and (b) more general than needed for clear().

This commit changes clear() to do the work itself. This modest change
was first proposed in #74172, where the reviewer rejected it because
there was insufficient evidence that Vec::clear()'s performance
mattered enough to justify the change. Recent changes within rustc have
made Vec::clear() hot within macro_parser.rs, so the change is now
clearly worthwhile.

Note that this will also benefit String::clear(), because it just
calls Vec::clear().

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[nnethercote]

cc @ecstatic-morse

[nnethercote]

Here are some local measurements of instruction counts for check full builds. Crates marked with * are from the rustc-perf suite.

Benchmark	Profile	Scenario	% Change	Significance Factor?
async-std-1.10.0	check	full	-2.25%	11.23x
time-macros-0.2.3	check	full	-2.15%	10.76x
quote-stress	check	full	-1.67%	8.37x
yansi-0.5.0	check	full	-1.13%	5.64x
web-sys-0.3.56	check	full	-0.70%	3.52x
num-derive-0.3.3	check	full	-0.60%	3.01x
futures-macro-0.3.19	check	full	-0.57%	2.85x
*deep-vector	check	full	-0.52%	2.60x
ctor-0.1.21	check	full	-0.56%	2.81x
pest_generator-2.1.3	check	full	-0.51%	2.57x
mockall_derive-0.11.0	check	full	-0.51%	2.53x
scroll_derive-0.11.0	check	full	-0.45%	2.27x
serde_derive-1.0.136	check	full	-0.42%	2.10x
inotify-0.10.0	check	full	-0.36%	1.79x

[nnethercote]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 27bddcb with merge 7e5a405eec6891b9459ca262ea526e966fae0fa4...

[rust-log-analyzer]

The job x86_64-gnu-llvm-12 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

failures:

---- [codegen] codegen/vec-clear.rs stdout ----

error: verification with 'FileCheck' failed
status: exit status: 1
command: "/usr/lib/llvm-12/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll" "/checkout/src/test/codegen/vec-clear.rs" "--check-prefixes" "CHECK,NONMSVC"
stdout: none
--- stderr -------------------------------
/checkout/src/test/codegen/vec-clear.rs:8:16: error: CHECK-NOT: excluded string found in input
 // CHECK-NOT: load
               ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll:17:18: note: found here
 %_2.i.i.i.i.i = load i32*, i32** %0, align 8, !alias.scope !12, !nonnull !17, !noundef !17
                 ^~~~
/checkout/src/test/codegen/vec-clear.rs:9:16: error: CHECK-NOT: excluded string found in input
 // CHECK-NOT: icmp
               ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll:20:24: note: found here
 %_5.i.i.i.i.i.i.i.i = icmp eq i64 %_6.i.i.i.i.i.i.i.i, 0

Input file: /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/vec-clear/vec-clear.ll
Check file: /checkout/src/test/codegen/vec-clear.rs


-dump-input=help explains the following input dump.
Input was:
<<<<<<
       .
       .
       .
       .
      12: start:
      13:  tail call void @llvm.experimental.noalias.scope.decl(metadata !2)
      14:  tail call void @llvm.experimental.noalias.scope.decl(metadata !5) #5, !noalias !2
      15:  tail call void @llvm.experimental.noalias.scope.decl(metadata !8) #5, !noalias !11
      16:  %0 = getelementptr inbounds %"alloc::vec::Vec<u32>", %"alloc::vec::Vec<u32>"* %x, i64 0, i32 0, i32 0
      17:  %_2.i.i.i.i.i = load i32*, i32** %0, align 8, !alias.scope !12, !nonnull !17, !noundef !17
not:8                      !~~~                                                                       error: no match expected
      18:  %1 = ptrtoint i32* %_2.i.i.i.i.i to i64
      19:  %_6.i.i.i.i.i.i.i.i = and i64 %1, 3
      20:  %_5.i.i.i.i.i.i.i.i = icmp eq i64 %_6.i.i.i.i.i.i.i.i, 0
not:9                            !~~~                               error: no match expected
      21:  br i1 %_5.i.i.i.i.i.i.i.i, label %bb2.i.i.i.i.i.i.i, label %bb7.i.i.i.i.i.i.i
      22: 
      23: bb2.i.i.i.i.i.i.i: ; preds = %start
      24:  %2 = getelementptr inbounds %"alloc::vec::Vec<u32>", %"alloc::vec::Vec<u32>"* %x, i64 0, i32 1
      25:  %_7.i.i.i = load i64, i64* %2, align 8, !alias.scope !18
       .
       .
>>>>>>
------------------------------------------

[bors]

☀️ Try build successful - checks-actions
Build commit: 7e5a405eec6891b9459ca262ea526e966fae0fa4 (7e5a405eec6891b9459ca262ea526e966fae0fa4)

[rust-timer]

Queued 7e5a405eec6891b9459ca262ea526e966fae0fa4 with parent 60e50fc, future comparison URL.

[nnethercote]

The failing codegen test (vec-clear.rs) was added in #52908. From before then until now, Vec::clear() just called Vec::truncate() with a zero length. The body of Vec::truncate() has changed a lot since then. Now that Vec::clear() is doing actual work itself, and not just calling Vec::truncate(), it's not surprising that its generated code includes a load and an icmp. I think it's reasonable to remove this test.

[rust-timer]

Finished benchmarking commit (7e5a405eec6891b9459ca262ea526e966fae0fa4): comparison url.

Summary:

• Primary benchmarks: 😿 relevant regression found
• Secondary benchmarks: no relevant changes found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	0	0	0	1
mean2	1.7%	N/A	N/A	N/A	1.7%
max	1.7%	N/A	N/A	N/A	1.7%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led 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-review -S-waiting-on-perf +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[nnethercote]

Huh... my local perf run showed nice wins, but the CI perf run showed basically nothing. CI builds do PGO, I wonder if that explains the difference. Anyway, not worth pursuing this further.