starred/psst

Fork 0

mirror of https://github.com/jpochyla/psst.git synced 2026-04-27 15:35:56 +03:00

[GH-ISSUE #12] High CPU usage #10

New issue

Closed

opened 2026-02-28 14:29:55 +03:00 by kerem · 9 comments

kerem commented

2026-02-28 14:29:55 +03:00

Owner

Originally created by @keeslinp on GitHub (Jan 4, 2021).
Original GitHub issue: https://github.com/jpochyla/psst/issues/12

I wonder if something is off with my setup because I get pegged at 100% CPU usage when I look up the app in activity monitor. The app seems to run just fine, no noticeable frame drops or anything, but the high CPU usage is concerning. Totally understand if that is a TODO that you aren't worrying about yet, I'm mostly just curious / reporting it in case it is an environment compatibility issue. I'm on a MBP with Catalina

Originally created by @keeslinp on GitHub (Jan 4, 2021). Original GitHub issue: https://github.com/jpochyla/psst/issues/12 I wonder if something is off with my setup because I get pegged at 100% CPU usage when I look up the app in activity monitor. The app seems to run just fine, no noticeable frame drops or anything, but the high CPU usage is concerning. Totally understand if that is a TODO that you aren't worrying about yet, I'm mostly just curious / reporting it in case it is an environment compatibility issue. I'm on a MBP with Catalina

kerem closed this issue

2026-02-28 14:29:56 +03:00

kerem commented

2026-02-28 14:29:56 +03:00

Author

Owner

@jpochyla commented on GitHub (Jan 4, 2021):

Hi! That's 100% CPU during playback, without any interaction? I've recently optimized the loudness spectrum display which used to be really intesive to paint. Are you on latest master? Thanks!

@jpochyla commented on GitHub (Jan 4, 2021): Hi! That's 100% CPU during playback, without any interaction? I've recently optimized the loudness spectrum display which used to be really intesive to paint. Are you on latest master? Thanks!

kerem commented

2026-02-28 14:29:56 +03:00

Author

Owner

@keeslinp commented on GitHub (Jan 4, 2021):

Yeah, playback but no interaction. I just reloaded it and it seems like the CPU usage slowly goes up the more views I open. If I start opening different playlists and then go to the library it goes up to around 70% and stays there. When I first open the app if I don't go anywhere it hovers at around 15%.

If I pause playback the usage drops to 0 immediately, but if I hit play again it comes back up.

Interestingly if I close the window (just pressing x), the music keeps playing and the CPU usage drops down to the single digits.

@keeslinp commented on GitHub (Jan 4, 2021): Yeah, playback but no interaction. I just reloaded it and it seems like the CPU usage slowly goes up the more views I open. If I start opening different playlists and then go to the library it goes up to around 70% and stays there. When I first open the app if I don't go anywhere it hovers at around 15%. If I pause playback the usage drops to 0 immediately, but if I hit play again it comes back up. Interestingly if I close the window (just pressing x), the music keeps playing and the CPU usage drops down to the single digits.

kerem commented

2026-02-28 14:29:56 +03:00

Author

Owner

@jpochyla commented on GitHub (Jan 5, 2021):

Thanks for the input! Performance is definitely one of the main priorities. Are you testing this with the release build? Anyway, I'm not sure if you're interested about the details, but here they are.

I just reloaded it and it seems like the CPU usage slowly goes up the more views I open.

Because the main views are lazily initialized and cached (i.e. when you open the Library, and then some playlist, and then something else, widgets for all of these are kept in memory, because initializing all of them can be slow, especially for the library), and all track lists depend on the information about the current playback, they are traversed on any playback change. I suspect they are traversed too often and there might be some possible wins here.

Another issue is that with Druid on master, Mac apps always repaint the whole window, even when a small rect is invalidated. So i.e. when we paint the seekbar every 100ms or so, the whole window is painted. There is a partial paint PR pending at the Druid repo and will help massively.

If I pause playback the usage drops to 0 immediately, but if I hit play again it comes back up.

Because the state is not changing, the app is just idling and also there's no decoding being done.

Interestingly if I close the window (just pressing x), the music keeps playing and the CPU usage drops down to the single digits.

At that point just the decoding/playback machinery is active and all the widgets are gone.

@jpochyla commented on GitHub (Jan 5, 2021): Thanks for the input! Performance is definitely one of the main priorities. Are you testing this with the release build? Anyway, I'm not sure if you're interested about the details, but here they are. > I just reloaded it and it seems like the CPU usage slowly goes up the more views I open. Because the main views are lazily initialized and cached (i.e. when you open the Library, and then some playlist, and then something else, widgets for all of these are kept in memory, because initializing all of them can be slow, especially for the library), and all track lists depend on the information about the current playback, they are traversed on any playback change. I suspect they are traversed too often and there might be some possible wins here. Another issue is that with Druid on master, Mac apps always repaint the whole window, even when a small rect is invalidated. So i.e. when we paint the seekbar every 100ms or so, the whole window is painted. There is a partial paint PR pending at the Druid repo and will help massively. > If I pause playback the usage drops to 0 immediately, but if I hit play again it comes back up. Because the state is not changing, the app is just idling and also there's no decoding being done. > Interestingly if I close the window (just pressing x), the music keeps playing and the CPU usage drops down to the single digits. At that point just the decoding/playback machinery is active and all the widgets are gone.

kerem commented

2026-02-28 14:29:56 +03:00

Author

Owner

@Heychsea commented on GitHub (Jan 5, 2021):

I can confirm that it does seem linked to the repaint. I have tested on both release and debug build. I have included some traces (For the Apple Instruments tool) that seem to confirm your hypothesis.
psst-repaint.trace.zip

@Heychsea commented on GitHub (Jan 5, 2021): I can confirm that it does seem linked to the repaint. I have tested on both release and debug build. I have included some traces (For the Apple Instruments tool) that seem to confirm your hypothesis. [psst-repaint.trace.zip](https://github.com/jpochyla/psst/files/5771025/psst-repaint.trace.zip)

kerem commented

2026-02-28 14:29:57 +03:00

Author

Owner

@keeslinp commented on GitHub (Jan 5, 2021):

Yeah, it was in release. Good to know! It definitely felt like a "rendering too much" type of a problem.

@keeslinp commented on GitHub (Jan 5, 2021): Yeah, it was in release. Good to know! It definitely felt like a "rendering too much" type of a problem.

kerem commented

2026-02-28 14:29:57 +03:00

Author

Owner

@synox commented on GitHub (Jul 13, 2021):

I also see the same issue with the current dev build.

@synox commented on GitHub (Jul 13, 2021): I also see the same issue with the current dev build.

kerem commented

2026-02-28 14:29:57 +03:00

Author

Owner

@jpochyla commented on GitHub (Jul 13, 2021):

I also see the same issue with the current dev build.

I'm sorry, but reports like this, without any further information, are useless.

@jpochyla commented on GitHub (Jul 13, 2021): > I also see the same issue with the current dev build. I'm sorry, but reports like this, without any further information, are useless.

kerem commented

2026-02-28 14:29:57 +03:00

Author

Owner

@jpochyla commented on GitHub (Nov 30, 2021):

I just reloaded it and it seems like the CPU usage slowly goes up the more views I open.

Fixed in master

@jpochyla commented on GitHub (Nov 30, 2021): > I just reloaded it and it seems like the CPU usage slowly goes up the more views I open. Fixed in master

kerem commented

2026-02-28 14:29:57 +03:00

Author

Owner

@keeslinp commented on GitHub (Dec 2, 2021):

Just gave it a try and it is super smooth and basically no usage so whatever changed definitely worked! Thanks!

@keeslinp commented on GitHub (Dec 2, 2021): Just gave it a try and it is super smooth and basically no usage so whatever changed definitely worked! Thanks!