-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
Graphs #22
Comments
rusty-endsong-parser/stuff/ideas.md Lines 41 to 44 in 57be173
rusty-endsong-parser/stuff/ideas.md Line 58 in 57be173
|
the Python version uses matplotlib https://github.com/fsktom/endsong-parser-python |
probably plotly.rs I like that |
even if plotters is used by FAAAR more crates and seems more flexible but probably more difficult to get in to |
Use multiple plotly traces for a compare command? (e.g. compare two artists) |
I love the sensible defaults in plotly. I don't have to manually scald the graph or set the dimensions <3 |
https://github.com/flamegraph-rs/flamegraph#systems-performance-work-guided-by-flamegraphs for performance profiling |
W T F fn gather_artist_date(
entries: &Vec<SongEntry>,
art: &Artist,
start: &DateTime<Tz>,
end: &DateTime<Tz>,
) -> u32 {
let mut plays = 0;
for entry in entries {
let artist = Artist::from_str(&entry.artist);
if artist == *art && entry.timestamp.ge(start) && entry.timestamp.le(end) {
plays += 1;
}
}
plays
} ChatGPT recommendation with some changes of mine -> fn gather_artist_date(
entries: &[SongEntry],
art: &Artist,
start: &DateTime<Tz>,
end: &DateTime<Tz>,
) -> usize {
entries
.iter()
.filter(|entry| {
entry.artist.eq(&art.name) && entry.timestamp.ge(start) && entry.timestamp.le(end)
})
.count()
} |
Ok, it seems like constantly creating a new Artist was the reason for the low performance and the functional-style iterator thingy did not improve performance (very likely due to compiler optimizations with |
The problem will be then more clutter with comparing albums and esp. songs |
See #22 <#22 (comment)> It looks worse and I think I've done this the first time, then went to creating aspects, dervied Eq for them, and compared those directly for it to look nicer. But seems like allocating a new aspect every time is very time-consuming. Comparing Strings directly without re-allocating anything is the way to go apparently. For normal single usage it doesn't matter. But I discovered this while working on plots and there I have to call such a function for every data point (bc I don't want to lower resolution it's equivalent to every time the aspect exists in the dataset heh). There it makes the code 6x faster
I'm so happy that I got it working 😄 |
|
such an easy fix.... |
ehm... on my MacBook... it's basically instant - less than a second I think
w t f |
Why is WSL performance sooo bad. And the input delay while typing... |
See #23 for plot comparison |
I've been procrastinating on this for so long. It's possibly the most important aspect of this program. It's the reason I created this - Python was so slow for creating relative (% of plays at each time) graphs...
It's been 11 months since I started this Rust project, time to include graphs :)
The text was updated successfully, but these errors were encountered: