Performance with larger lists really bad #20
Assignees
Comments
|
I just had a look and you were right. Initially I thought this must be because the progress bar makes multiple draw requests every second, but upon disabling it, the issue still persists. I have a feeling this has something to do with tview's drawing method (not totally sure). |
I was wrong. I think the slow down might be because of the constant fetching of current playlist from the mpd server |
aditya-K2
added a commit
that referenced
this issue
Sep 13, 2022
As mentioned at #20 (comment) The Slow Down was caused due to constant calls to the MPD Server for playlist info. Using Watcher to handle playlist event changes. Also when In SearchView upon adding Artist/Album due to constant change in playlists there was a slow down. Hence using CommandList for that.
Merged
|
Fixed with #35 |
aditya-K2
added a commit
that referenced
this issue
Oct 19, 2022
As Mentioned in #20 The Performance with larger list was very sluggish. PR #35 tried fixing it with reducing the server request. But during Empty Playlist checks there were constant server requests, which caused a bottleneck and with list sizes of greater than 6000 there was a slow down. This commit tries to fix that by checking the local Playlist.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm running gomp on a pretty powerful machine, yet with a larger playlist of over 1k entries the TUI feels awfully sluggish. Pressing arrow down for a few seconds and letting it go makes the selection continue to advance for several seconds before it stops.
The text was updated successfully, but these errors were encountered: