Add #[inline] to core debug assertion helpers

[saethlin]

These functions are called a lot and not inlined by default in a dev compiler. Adding #[inline] should improve things in a dev workflow and be irrelevant in the distributed library.

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[cuviper]

irrelevant in the distributed library.

I guess we're not set up to perf test it then, but it makes sense to me!

@bors r+

[bors]

📌 Commit 9d4a8e4dc5661125fe3f6b0abde369996d5f0127 has been approved by cuviper

It is now in the queue for this repository.

[matthiaskrgr]

@bors rollup=never

[bors]

⌛ Testing commit 9d4a8e4dc5661125fe3f6b0abde369996d5f0127 with merge 88e1282e2e1ca906a8d2c1636b669b0e3dc63cd5...

[bors]

💔 Test failed - checks-actions

[cuviper]

@bors r+

[bors]

📌 Commit 65e52bb has been approved by cuviper

It is now in the queue for this repository.

[bors]

⌛ Testing commit 65e52bb with merge 31395ec...

[bors]

☀️ Test successful - checks-actions
Approved by: cuviper
Pushing 31395ec to master...

[rust-timer]

Finished benchmarking commit (31395ec): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.7%	[0.6%, 0.7%]	2
Regressions ❌ (secondary)	0.5%	[0.3%, 0.6%]	5
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-0.3%, 0.7%]	5

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)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	2.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.1%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

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
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.4%, -0.0%]	70
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.0%]	15
All ❌✅ (primary)	-0.2%	[-0.4%, -0.0%]	70

Bootstrap: 652.459s -> 650.065s (-0.37%)

[nnethercote]

The small number of icount regressions are inconsequential. The large number of binary size reductions are very nice.

@rustbot label: +perf-regression-triaged

[saethlin]

I'm shocked this matters at all. Aren't all these functions trivially unreachable and optimized out in a release build of the standard library? I mean, the mir-opt test change suggests that some bits of them remain, which is disconcerting for sure.

[therealprof]

I'm shocked this matters at all. Aren't all these functions trivially unreachable and optimized out in a release build of the standard library? I mean, the mir-opt test change suggests that some bits of them remain, which is disconcerting for sure.

Not sure. I've been complaining a lot about the subideal inlining in libcore for years since this has been a critical problem for folks who want to write embedded code and debug it, too, because the produced binaries without optimisation are so ginormous that they don't even fit in flash. And if they do, they're often running so slow that some strict timing requirements of some hardware can't be fulfilled.

And no, embedded developers pretty much never care about debugging libcore on microcontrollers, so it doesn't make sense to generate easily debuggable and super-slow code for trivial operations -- at least not by default as it is now.

[saethlin]

I don't think any of what you have said is relevant to the perf results above. All the perf numbers above are using the precompiled standard library, which has debug assertions disabled.