[GH-ISSUE #335] Improve parallelism #108

New issue

Closed

opened 2026-02-27 20:23:09 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 20:23:09 +03:00

Owner

Originally created by @marioortizmanero on GitHub (Jul 3, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/335

Is your feature request related to a problem? Please describe.

I'm not super happy with how RSpotify handles parallelism. We have a Mutex at the core of the implementation, which is locked and released for every single request. This is necessary for internal mutability in order to refresh the access token when it's expired. However, this feature may not even be activated, and even when it is, the number of writes is absolutely minuscule in comparison to the reads.

We should use a synchronization strategy that focuses on the performance of the reads instead. I still have to investigate more about this, but I wanted to open this issue in case anyone comes up with other ideas.

It would also be great to have benchmarks for the library so that we can actually measure the improvements. Otherwise they may not e worth implementing. At least one of them should be like a general use case with lots of load and requests. We could take a look of RSpotify users and see if any of them already have benchmarks.

Describe the solution you'd like

A first idea would be to use a std::sync::Mutex even in the case of asynchronous programming. This is often recommended when the mutex is only locked shortly, since asynchronous mutexes incur more overhead. It would be a first step, but I imagine that we can try with a completely different synchronization method that focuses on the reads.

Originally created by @marioortizmanero on GitHub (Jul 3, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/335 **Is your feature request related to a problem? Please describe.** I'm not super happy with how RSpotify handles parallelism. We have a `Mutex` at the core of the implementation, which is locked and released for every single request. This is necessary for internal mutability in order to refresh the access token when it's expired. However, this feature may not even be activated, and even when it is, the number of writes is absolutely minuscule in comparison to the reads. We should use a synchronization strategy that focuses on the performance of the reads instead. I still have to investigate more about this, but I wanted to open this issue in case anyone comes up with other ideas. It would also be great to have benchmarks for the library so that we can actually measure the improvements. Otherwise they may not e worth implementing. At least one of them should be like a general use case with lots of load and requests. We could take a look of RSpotify users and see if any of them already have benchmarks. **Describe the solution you'd like** A first idea would be to use a `std::sync::Mutex` even in the case of asynchronous programming. This is often recommended when the mutex is only locked shortly, since asynchronous mutexes incur more overhead. It would be a first step, but I imagine that we can try with a completely different synchronization method that focuses on the reads.

kerem

2026-02-27 20:23:09 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 20:23:10 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jun 25, 2023):

Message to comment on stale issues. If none provided, will not mark issues stale

@github-actions[bot] commented on GitHub (Jun 25, 2023): Message to comment on stale issues. If none provided, will not mark issues stale