Mark <mem::DropGuard as Drop>::drop as #[inline] - #162064
Conversation
|
@GrigorenkoPV: 🔑 Insufficient privileges: not in try users |
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Mark `<mem::DropGuard as Drop>::drop` as `#[inline]`
|
r? clarfonthey since I reviewed the other change |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (4606595): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 2.6%, secondary -2.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.5%, secondary -1.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 475.395s -> 473.906s (-0.31%) |
|
Tempted to say these are a net positive but will take another look later. |
|
This is positive, yes, especially if you look at binary sizes - in some benchmarks, like This doesn't address the original regression so we have to be a bit careful to asses the impact overall. It's possible (but unlikely in my opinion) that this is only positive because #161702 was negative and the benefit of this PR largely disappears when we address the root cause. Not a blocking concern, but something to keep in mind for example if later results come back unexpectedly red. |
#161702 has caused a perf regression. As suggested in #161702 (review), this might help.
drop_guardin some places in {core,alloc,std}" #162067core::mem::DropGuard#144426@bors try @rust-timer queue
(I probably don't have permissions for those)