[GH-ISSUE #160] There are a lot of unnecessary allocations in the library #56

New issue

Closed

opened 2026-02-27 20:22:51 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 20:22:51 +03:00

Owner

Originally created by @kstep on GitHub (Nov 24, 2020).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/160

Is your feature request related to a problem? Please describe.
There are a lot of places with unnecessary clones/vector constructions/other allocations.
E.g. get_id() function does things like this:

if _type.to_string() != fields[len - 2] { ... }

This leads to unnecessary allocation of a piece of memory, immediately thrown away.
It probably should be if _type.as_str() != fields[len -2].

Also, there are a lot of places with something_ids.into_iter().collect::<Vec<_>>().join(","), which allocates a vector just to throw it away. It can be replaced with just something_ids.into_iter().join(",") using itertools crate, which is very efficient, trying hard to allocate as little memory as possible and joins elements in one pass instead of two.

Another example is &format!("me/player/repeat?state={}", state.to_string()), why allocate a transient string here? It should be something like &format!("me/player/repeat?state={}", state.as_str()).

Describe the solution you'd like
Use &'static str to get a string representation of enums. Use slices and iterators without transient allocations with collect() wherever possible. Use enums to compare things instead of strings. Avoid .to_string() unless totally necessary.

Describe alternatives you've considered
Leave things as they are. But I think using unnecessary allocations in languages like Rust is a sin, as doing so is losing the point of such a low-level language at all.

Originally created by @kstep on GitHub (Nov 24, 2020). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/160 **Is your feature request related to a problem? Please describe.** There are a lot of places with unnecessary clones/vector constructions/other allocations. E.g. `get_id()` function does things like this: ``` if _type.to_string() != fields[len - 2] { ... } ``` This leads to unnecessary allocation of a piece of memory, immediately thrown away. It probably should be `if _type.as_str() != fields[len -2]`. Also, there are a lot of places with `something_ids.into_iter().collect::<Vec<_>>().join(",")`, which allocates a vector just to throw it away. It can be replaced with just `something_ids.into_iter().join(",")` using `itertools` crate, which is very efficient, trying hard to allocate as little memory as possible and joins elements in one pass instead of two. Another example is `&format!("me/player/repeat?state={}", state.to_string())`, why allocate a transient string here? It should be something like `&format!("me/player/repeat?state={}", state.as_str())`. **Describe the solution you'd like** Use `&'static str` to get a string representation of enums. Use slices and iterators without transient allocations with `collect()` wherever possible. Use enums to compare things instead of strings. Avoid `.to_string()` unless totally necessary. **Describe alternatives you've considered** Leave things as they are. But I think using unnecessary allocations in languages like Rust is a sin, as doing so is losing the point of such a low-level language at all.

kerem

2026-02-27 20:22:51 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Nov 24, 2020):

I completely agree, I would like to reduce the number of allocations in this crate as well. But IMO that's currently very low priority, we're under some refactoring right now and lots of stuff could change. For instance I wanted to rewrite get_id completely because the function itself is quite messy. Maybe after we release the next version we can focus on things like this.

For simple things you can always open a PR and I'll gladly review it, but I wouldn't want to lose too much time on this yet.

@marioortizmanero commented on GitHub (Nov 24, 2020): I completely agree, I would like to reduce the number of allocations in this crate as well. But IMO that's currently very low priority, we're under some refactoring right now and lots of stuff could change. For instance I wanted to rewrite `get_id` completely because the function itself is quite messy. Maybe after we release the next version we can focus on things like this. For simple things you can always open a PR and I'll gladly review it, but I wouldn't want to lose too much time on this yet.

kerem commented

2026-02-27 20:22:52 +03:00

Author

Owner

@marioortizmanero commented on GitHub (Dec 29, 2022):

This is now too old to be relevant. If anyone still thinks there are too many allocations (only if removing them doesn't hurt usability), please open a new issue with examples from the codebase. Thanks!

@marioortizmanero commented on GitHub (Dec 29, 2022): This is now too old to be relevant. If anyone still thinks there are too many allocations (only if removing them doesn't hurt usability), please open a new issue with examples from the codebase. Thanks!

kerem referenced this issue

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

[PR #56] [MERGED] oauth2.rs: Fix get_access_token #214