Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily #96979

SabrinaJewson · 2022-05-12T16:05:48Z

This would be very useful for futures — I think it’s pretty much always what they want to do instead of *waker = cx.waker().clone().

Tracking issue: #98287

r? rust-lang/libs-api @rustbot label T-libs-api -T-libs

rust-highfive · 2022-05-12T16:05:51Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

JohnTitor · 2022-06-20T08:06:24Z

Could you add a tracking issue here as well?

JohnCSimon · 2022-07-24T05:47:41Z

triage:

Could you add a tracking issue here as well?

@SabrinaJewson ☝️

SabrinaJewson · 2022-07-24T06:16:13Z

I think I did that already.

a1phyr · 2023-01-02T14:24:24Z

I think that overriding Clone::clone_from would be preferable over adding a new method.

I agree that it is less discoverable though.

SabrinaJewson · 2023-01-02T16:42:09Z

That is a very good point, I forgot that method existed. I think I will change this PR to implement that instead — a note in the documentation would probably be sufficient.

rustbot · 2023-01-02T16:42:32Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

conradludgate

Semi-related to this PR. Should Arc get a similar impl?

pitaj · 2023-05-05T03:54:13Z

@joshtriplett ping from triage, no movement for 4 months. What's the status of this PR?

@SabrinaJewson FYI you may need to squash your commits

workingjubilee · 2023-07-26T03:31:10Z

Please rebase to remove the master-merge.

r? @workingjubilee
@rustbot author

This looks plausible, but I have one question: Are we sure it's okay to elide the possible clone effect?
https://github.com/rust-lang/rust/blob/834ed29b5882a20c5399a85cd7ff443ef0d03f91/library/core/src/task/wake.rs#L81-L90

coolreader18 · 2023-11-02T02:05:05Z

library/core/src/task/wake.rs

@@ -382,6 388,13 @@ impl Clone for Waker {
 waker: unsafe { (self.waker.vtable.clone)(self.waker.data) },
 }
 }
+
+ #[inline]
+ fn clone_from(&mut self, source: &Self) {


Unsure if it'd make sense to do this here or another PR, but it might be good to add docs here to aid discoverability (I believe rustdoc pops open trait impls by default when an associated item has docs? or at least it'll catch the eye when scanning the page), and also especially since the will_wake docs link here. I can't remember it off the top of my head, but I'm almost certain there's prior art in the standard library of adding docs to associated items of an impl.

I think we can handle that in a followup. It might be a good idea to doc ~all the overridden clone_froms in std as a single PR.

rfcbot · 2023-11-04T13:31:38Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

dtolnay · 2023-11-05T20:57:05Z

@bors r=workingjubilee

bors · 2023-11-05T20:57:09Z

📌 Commit 6cdb7df has been approved by workingjubilee

It is now in the queue for this repository.

bors · 2023-11-05T21:44:28Z

⌛ Testing commit 6cdb7df with merge fee5518...

bors · 2023-11-05T23:46:07Z

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing fee5518 to master...

rust-timer · 2023-11-06T13:27:26Z

Finished benchmarking commit (fee5518): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-0.3%, -0.3%]	1

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)	0.6%	[0.5%, 0.9%]	3
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	4
Improvements ✅ (secondary)	-4.3%	[-4.3%, -4.3%]	1
All ❌✅ (primary)	-0.0%	[-0.6%, 0.9%]	7

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.5%	[0.5%, 0.6%]	3
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.6%, 0.6%]	6

Binary size

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

Bootstrap: 637.169s -> 636.185s (-0.15%)
Artifact size: 304.52 MiB -> 304.50 MiB (-0.01%)

wiseaidev · 2024-01-11T17:50:55Z

Hey friends. I am trying to understand the practicality of this feature. Let's consider the following example:

use std::task::{Context, Poll, Waker};
use std::pin::Pin;
use futures::task::noop_waker_ref;

#[derive(Debug, Clone)]
struct MyTask {
    id: usize,
}

struct MyFuture {
    waker: Waker,
    task: MyTask,
}

impl MyFuture {
    fn new(id: usize) -> Self {
        let task = MyTask { id };
        let waker = noop_waker_ref();
        MyFuture { waker: waker.clone(), task }
    }
}

impl futures::Future for MyFuture {
    type Output = ();

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        let cloned_waker = self.waker.clone();
        println!("Cloned Waker address: {:?}", &cloned_waker as *const Waker);

        // `clone_from` used here
        //  Note: `Waker::clone_from(cx.waker(), &self.waker)` returns
        //         ----------------- ^^^^^^^^^^ types differ in mutability
        //                               |
        //                               arguments to this function are incorrect
        //
        // = note: expected mutable reference `&mut Waker`
        //              found reference `&Waker`
        let mut optimized_waker = cx.waker().clone_from(&&self.waker);
        println!("Optimized Waker address: {:?}", std::ptr::addr_of!(optimized_waker));

        Poll::Ready(())
    }
}

fn main() {
    // Create two MyFuture with the same task ID
    let my_future1 = MyFuture::new(42);
    let my_future2 = MyFuture::new(42);

    let mut pinned1 = Box::pin(my_future1);
    let mut pinned2 = Box::pin(my_future2);

    // Create a dummy Context
    let mut cx = Context::from_waker(&noop_waker_ref());

    // Poll the futures
    let _result1 = futures::Future::poll(pinned1.as_mut(), &mut cx);
    let _result2 = futures::Future::poll(pinned2.as_mut(), &mut cx);
}

This would result with the following being displayed on the terminal:

Cloned Waker address: 0x7fffaf9e6538
Optimized Waker address: 0x7fffaf9e6597
Cloned Waker address: 0x7fffaf9e6538
Optimized Waker address: 0x7fffaf9e6597

As evident from the output, both 'Cloned Waker' and 'Optimized Waker' share identical addresses for each corresponding pair. This suggests that the clone_from optimization does not trigger any difference in terms of memory addresses. Therefore, I am currently pondering how this feature might be beneficial for end users.

Any additional info about this feature would be appreciated. Thanks!

SabrinaJewson · 2024-01-11T18:16:06Z

There are a couple of issues here. Firstly, you have the argument order the wrong way round: a.clone_from(b) will set a to the (cloned) value of b, not the other way around. Therefore, since futures need to store cx.waker() inside the future itself for later use, in your function you should write self.waker.clone_from(cx.waker()); (and correspondingly self.waker = cx.waker().clone()). The current code only clones a reference to a waker, which is useless because it’s Copy anyway.

Secondly, using addr_of! on a &Waker will only retrieve the address of the local variable holding the waker. But this isn’t important to you at all — what matters is the interior pointer held by the waker. The Debug implementation of the waker should print this.

Thirdly, cloning the noop_waker_ref() will be a noöp anyway, because the noöp waker holds no state, and so there is nothing to be gained by using this optimization to avoid cloning it. The interior address will be the null pointer in both cases, which you can verify by running the version of your code with the two above issues fixed.

Even when one builds a waker via the Wake trait, the difference is not observable, since the effect is the same:

Without clone_from, the Arc’s reference count is incremented, but then immediately decremented;
With clone_from, the Arc’s reference count remains constant.

To test this feature properly, you thus have to make a custom waker that performs some sideëffect on clone and/or drop. You can see in the output of this program does not clone in the clone_from sections.

wiseaidev · 2024-01-11T18:42:32Z

Thanks for the clear explanation @SabrinaJewson! That's really helpful. I tried your example on both 1.74 and 1.75, and noticed the following optimization being done in this PR:

First poll:
With `clone`:
cloning
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
With `clone_from`:
- cloning
- dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
Second poll:
With `clone`:
cloning
dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
With `clone_from`:
- cloning
- dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
dropping
dropping

So, clone_from would avoid redundant cloning and drooping each time being called unlike the case of clone. nice!

Pkgsrc changes: * Adjust patches and cargo checksums to new versions. * For an external LLVM, set dependency of llvm >= 16, in accordance with the upstream changes. * Mark that on NetBSD we now need >= 9.0, so 8.x is no longer supported. * On NetBSD/sparc64 10.x, we now need GCC 12 to build the embedded LLVM, which is version 17; apparently GCC 10.4 or 10.5 mis-compiles it, resulting in an illegal instruction fault during the build. Ref. rust-lang/rust#117231 Upstream changes: Version 1.75.0 (2023-12-28) ========================== - [Stabilize `async fn` and return-position `impl Trait` in traits.] (rust-lang/rust#115822) - [Allow function pointer signatures containing `&mut T` in `const` contexts.] (rust-lang/rust#116015) - [Match `usize`/`isize` exhaustively with half-open ranges.] (rust-lang/rust#116692) - [Guarantee that `char` has the same size and alignment as `u32`.] (rust-lang/rust#116894) - [Document that the null pointer has the 0 address.] (rust-lang/rust#116988) - [Allow partially moved values in `match`.] (rust-lang/rust#103208) - [Add notes about non-compliant FP behavior on 32bit x86 targets.] (rust-lang/rust#113053) - [Stabilize ratified RISC-V target features.] (rust-lang/rust#116485) Compiler -------- - [Rework negative coherence to properly consider impls that only partly overlap.] (rust-lang/rust#112875) - [Bump `COINDUCTIVE_OVERLAP_IN_COHERENCE` to deny, and warn in dependencies.] (rust-lang/rust#116493) - [Consider alias bounds when computing liveness in NLL.] (rust-lang/rust#116733) - [Add the V (vector) extension to the `riscv64-linux-android` target spec.] (rust-lang/rust#116618) - [Automatically enable cross-crate inlining for small functions] (rust-lang/rust#116505) - Add several new tier 3 targets: - [`csky-unknown-linux-gnuabiv2hf`] (rust-lang/rust#117049) - [`i586-unknown-netbsd`] (rust-lang/rust#117170) - [`mipsel-unknown-netbsd`] (rust-lang/rust#117356) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily.] (rust-lang/rust#96979) - [Implement `BufRead` for `VecDeque<u8>`.] (rust-lang/rust#110604) - [Implement `FusedIterator` for `DecodeUtf16` when the inner iterator does.] (rust-lang/rust#110729) - [Implement `Not, Bit{And,Or}{,Assign}` for IP addresses.] (rust-lang/rust#113747) - [Implement `Default` for `ExitCode`.] (rust-lang/rust#114589) - [Guarantee representation of None in NPO] (rust-lang/rust#115333) - [Document when atomic loads are guaranteed read-only.] (rust-lang/rust#115577) - [Broaden the consequences of recursive TLS initialization.] (rust-lang/rust#116172) - [Windows: Support sub-millisecond sleep.] (rust-lang/rust#116461) - [Fix generic bound of `str::SplitInclusive`'s `DoubleEndedIterator` impl] (rust-lang/rust#100806) - [Fix exit status / wait status on non-Unix `cfg(unix)` platforms.] (rust-lang/rust#115108) Stabilized APIs --------------- - [`Atomic*::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicUsize.html#method.from_ptr) - [`FileTimes`] (https://doc.rust-lang.org/stable/std/fs/struct.FileTimes.html) - [`FileTimesExt`] (https://doc.rust-lang.org/stable/std/os/windows/fs/trait.FileTimesExt.html) - [`File::set_modified`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.set_modified) - [`File::set_times`] (https://doc.rust-lang.org/stable/std/fs/struct.File.html#method.set_times) - [`IpAddr::to_canonical`] (https://doc.rust-lang.org/stable/core/net/enum.IpAddr.html#method.to_canonical) - [`Ipv6Addr::to_canonical`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.to_canonical) - [`Option::as_slice`] (https://doc.rust-lang.org/stable/core/option/enum.Option.html#method.as_slice) - [`Option::as_mut_slice`] (https://doc.rust-lang.org/stable/core/option/enum.Option.html#method.as_mut_slice) - [`pointer::byte_add`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_add) - [`pointer::byte_offset`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_offset) - [`pointer::byte_offset_from`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_offset_from) - [`pointer::byte_sub`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.byte_sub) - [`pointer::wrapping_byte_add`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_add) - [`pointer::wrapping_byte_offset`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_offset) - [`pointer::wrapping_byte_sub`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.wrapping_byte_sub) These APIs are now stable in const contexts: - [`Ipv6Addr::to_ipv4_mapped`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.to_ipv4_mapped) - [`MaybeUninit::assume_init_read`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.assume_init_read) - [`MaybeUninit::zeroed`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.zeroed) - [`mem::discriminant`] (https://doc.rust-lang.org/stable/core/mem/fn.discriminant.html) - [`mem::zeroed`] (https://doc.rust-lang.org/stable/core/mem/fn.zeroed.html) Cargo ----- - [Add new packages to `[workspace.members]` automatically.] (rust-lang/cargo#12779) - [Allow version-less `Cargo.toml` manifests.] (rust-lang/cargo#12786) - [Make browser links out of HTML file paths.] (rust-lang/cargo#12889) Rustdoc ------- - [Accept less invalid Rust in rustdoc.] (rust-lang/rust#117450) - [Document lack of object safety on affected traits.] (rust-lang/rust#113241) - [Hide `#[repr(transparent)]` if it isn't part of the public ABI.] (rust-lang/rust#115439) - [Show enum discriminant if it is a C-like variant.] (rust-lang/rust#116142) Compatibility Notes ------------------- - [FreeBSD targets now require at least version 12.] (rust-lang/rust#114521) - [Formally demote tier 2 MIPS targets to tier 3.] (rust-lang/rust#115238) - [Make misalignment a hard error in `const` contexts.] (rust-lang/rust#115524) - [Fix detecting references to packed unsized fields.] (rust-lang/rust#115583) - [Remove support for compiler plugins.] (rust-lang/rust#116412)

…lnay Document overrides of `clone_from()` in core/std As mentioned in rust-lang#96979 (comment) Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source". I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that. Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.

Rollup merge of rust-lang#122201 - coolreader18:doc-clone_from, r=dtolnay Document overrides of `clone_from()` in core/std As mentioned in rust-lang#96979 (comment) Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source". I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that. Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.

Document overrides of `clone_from()` in core/std As mentioned in rust-lang/rust#96979 (comment) Specifically, when an override doesn't just forward to an inner type, document the behavior and that it's preferred over simply assigning a clone of source. Also, change instances where the second parameter is "other" to "source". I reused some of the wording over and over for similar impls, but I'm not sure that the wording is actually *good*. Would appreciate feedback about that. Also, now some of these seem to provide pretty specific guarantees about behavior (e.g. will reuse the exact same allocation iff the len is the same), but I was basing it off of the docs for [`Box::clone_from`](https://doc.rust-lang.org/1.75.0/std/boxed/struct.Box.html#method.clone_from-1) - I'm not sure if providing those strong guarantees is actually good or not.

rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label May 12, 2022

rust-highfive assigned joshtriplett May 12, 2022

rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 12, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 12, 2022

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 20, 2022

SabrinaJewson mentioned this pull request Jun 20, 2022

Tracking Issue for task::Waker::update #98287

Closed

3 tasks

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 8, 2022

SabrinaJewson changed the title ~~Add Waker::update~~ Override Waker::clone_from to avoid cloning Wakers unnecessarily Jan 2, 2023

a1phyr approved these changes Jan 4, 2023

View reviewed changes

danielhenrymantilla approved these changes Apr 5, 2023

View reviewed changes

conradludgate approved these changes Apr 5, 2023

View reviewed changes

pitaj added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 5, 2023

rustbot assigned workingjubilee and unassigned joshtriplett Jul 26, 2023

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 26, 2023

Override Waker::clone_from to avoid cloning Wakers unnecessarily

6cdb7df

SabrinaJewson force-pushed the waker-update branch from 834ed29 to 6cdb7df Compare July 27, 2023 15:32

coolreader18 reviewed Nov 2, 2023

View reviewed changes

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Nov 4, 2023

dtolnay approved these changes Nov 5, 2023

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 5, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 5, 2023

bors merged commit fee5518 into rust-lang:master Nov 5, 2023
12 checks passed

rustbot added this to the 1.75.0 milestone Nov 5, 2023

bors mentioned this pull request Nov 6, 2023

Additional doc links and explanation of Wake. #116387

Merged

github-actions bot mentioned this pull request Nov 6, 2023

Automated pull from upstream master ferrocene/ferrocene#84

Merged

yoshuawuyts mentioned this pull request Nov 6, 2023

Use Waker::clone_from internally yoshuawuyts/futures-concurrency#160

Closed

SabrinaJewson deleted the waker-update branch November 6, 2023 17:41

apiraino removed the to-announce Announce this issue on triage meeting label Nov 9, 2023

coolreader18 mentioned this pull request Mar 8, 2024

Document overrides of clone_from() in core/std #122201

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily #96979

Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily #96979

SabrinaJewson commented May 12, 2022 •

edited

Loading

rust-highfive commented May 12, 2022

JohnTitor commented Jun 20, 2022

JohnCSimon commented Jul 24, 2022

SabrinaJewson commented Jul 24, 2022

a1phyr commented Jan 2, 2023

SabrinaJewson commented Jan 2, 2023

rustbot commented Jan 2, 2023

conradludgate left a comment

pitaj commented May 5, 2023 •

edited

Loading

workingjubilee commented Jul 26, 2023

coolreader18 Nov 2, 2023 •

edited

Loading

workingjubilee Nov 5, 2023 •

edited

Loading

rfcbot commented Nov 4, 2023

dtolnay commented Nov 5, 2023

bors commented Nov 5, 2023

bors commented Nov 5, 2023

bors commented Nov 5, 2023

rust-timer commented Nov 6, 2023

wiseaidev commented Jan 11, 2024

SabrinaJewson commented Jan 11, 2024

wiseaidev commented Jan 11, 2024

Override Waker::clone_from to avoid cloning Wakers unnecessarily #96979

Override Waker::clone_from to avoid cloning Wakers unnecessarily #96979

Conversation

SabrinaJewson commented May 12, 2022 • edited Loading

rust-highfive commented May 12, 2022

JohnTitor commented Jun 20, 2022

JohnCSimon commented Jul 24, 2022

SabrinaJewson commented Jul 24, 2022

a1phyr commented Jan 2, 2023

SabrinaJewson commented Jan 2, 2023

rustbot commented Jan 2, 2023

conradludgate left a comment

Choose a reason for hiding this comment

pitaj commented May 5, 2023 • edited Loading

workingjubilee commented Jul 26, 2023

coolreader18 Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

workingjubilee Nov 5, 2023 • edited Loading

Choose a reason for hiding this comment

rfcbot commented Nov 4, 2023

dtolnay commented Nov 5, 2023

bors commented Nov 5, 2023

bors commented Nov 5, 2023

bors commented Nov 5, 2023

rust-timer commented Nov 6, 2023

Overall result: ✅ improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

wiseaidev commented Jan 11, 2024

SabrinaJewson commented Jan 11, 2024

wiseaidev commented Jan 11, 2024

Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily #96979

Override `Waker::clone_from` to avoid cloning `Waker`s unnecessarily #96979

SabrinaJewson commented May 12, 2022 •

edited

Loading

pitaj commented May 5, 2023 •

edited

Loading

coolreader18 Nov 2, 2023 •

edited

Loading

workingjubilee Nov 5, 2023 •

edited

Loading