Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[optimization] move Sender/Receiver data #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Oct 23, 2024
Merged

[optimization] move Sender/Receiver data #6

merged 2 commits into from
Oct 23, 2024

Conversation

@cod10129
Copy link
Contributor

Your URLO post has attracted a contributor!

The implementation of Receiver looks like this:

pub struct Receiver<T> {
    shared_state: Arc<Mutex<SharedState<T>>>,
    recv_count: Arc<AtomicUsize>,
    next_id: Arc<AtomicUsize>,
}

That's three different Arcs! I optimized the code to have Receiver<T> look like this:

pub struct Receiver<T> {
    inner: Arc<ReceiverInner<T>>,
}

struct ReceiverInner<T> {
    shared_state: Arc<Mutex<SharedState<T>>>,
    recv_count: AtomicUsize,
    next_id: AtomicUsize,
}

(The Arc around shared_state is still necessary because the SharedState lives outside of the group of all Receivers on a channel. The recv_count and next_id fields are one per channel.)

This change is also mirrored on Sender/SenderInner.

I also took the liberty to fix various clippy warnings in the tests (try cargo clippy --all-targets).

Unresolved Questions

Should the structs have an Arc<Inner> holding the Arc<Mutex<SharedState>>, or should they have both the Arc<Inner> and shared state next to each other?
Basically, should Receiver look like this instead of the change I made?

pub struct Receiver<T> {
    shared_state: Arc<Mutex<SharedState<T>>>,
    inner: Arc<ReceiverInner>,
}

struct ReceiverInner {
    recv_count: AtomicUsize,
    next_id: AtomicUsize,
}

@mahdi-shojaee
Copy link
Owner

@cod10129 Thanks for your contribution. Did you run benchmarks, I mean cargo bench? And if yes, how much was the improvements?

@cod10129
Copy link
Contributor Author

@mahdi-shojaee I considered it yesterday when I made the PR, but realized that my results wouldn't be comparable to your results so I wrote doing benchmarking off. I just finished the results now and got great results, gaining up to 20% on certain tests. I observed that the tests with the biggest improvements were the ones with their execution time dominated by spawning senders/receivers, as I would have expected.
This code change caused the size of each channel endpoint to be reduced by 16 bytes and an Arc allocation. (To be honest, I was not expecting such big improvements from this change.)
I don't know how to regenerate the charts for the README, but I think you should after this.
(While you're responding, why are the ids in Queue usize? I would have picked out u16 or u32 -- I don't see those ids being used as indices anywhere, probably because I'm unfamiliar with the codebase)

@mahdi-shojaee
Copy link
Owner

Great! I'll run the benchmarks either today or tomorrow.

@cod10129
Copy link
Contributor Author

If you're going to do that you would have to run the benchmarks on a local clone of my fork and then merge that or just merge this PR to mahdi-shojaee/loole:master. (It's about the end of the third day since your last comment in your time zone, did you forget about this or have you just been busy?)
(And I really don't mean to rush you - I just want to remind you that this exists)

@mahdi-shojaee
Copy link
Owner

Sorry for the delay. I ran the benchmarks, and some improvements are noticeable. Thanks for your efforts!

However, could you please update your commits as follows:

  1. Rebase the SenderInner and ReceiverInner changes into a single commit.
  2. Do not include the Clippy commit, as the tests/flume_*.rs files should remain untouched—they are direct copies from the Flume project.

@cod10129
Add Sender/ReceiverInner types
e2516b4 
This commit optimizes performance in the Sender and Receiver types, as their two AtomicUsizes are now behind one Arc instead of two different ones.
@cod10129
fix Clippy warnings in code
480c0d6 
This does NOT include the tests/flume_* files, like you asked.
@cod10129
Copy link
Contributor Author

I learned some git commands from StackOverflow and got the changes fixed.
There is a commit about fixing Clippy warnings still in there, but it does not include the flume test files.
By the way, I have enabled the setting so you, as an owner of the loole repository, have write access to my fork as the PR is going through.

@mahdi-shojaee
Copy link
Owner

Ok, Thanks for your PR. I will merge both commits and in the next future will update the Clippy commit.

For now I will not update the benchmarks, as I'm currently working on a fix that is expected to significantly reduce performance.

@mahdi-shojaee mahdi-shojaee merged commit d292729 into mahdi-shojaee:master Oct 23, 2024
1 check passed
@mahdi-shojaee mahdi-shojaee added the enhancement New feature or request label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

enhancement New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@cod10129 @mahdi-shojaee