ramsayleung / rspotify

Spotify Web API SDK implemented on Rust
MIT License
639 stars 123 forks source link

Improve parallelism #335

Closed marioortizmanero closed 1 year ago

marioortizmanero commented 2 years ago

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.

github-actions[bot] commented 1 year ago

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