gomu icon indicating copy to clipboard operation
gomu copied to clipboard

Problem regarding cpu usage

Open tramhao opened this issue 3 years ago • 5 comments

I met a problem for both beep and mpd: When open the app, the cup usage for gomu in gotop for mpd is about 2%, and beep is about 20%. After pressing N for like 10 seconds or more (skip), the cup usage for mpd is 40% and beep is 50%, and they don't drop back.

I think it's probably related to the go routine for play. I mean, the player.Run is in go routing, and it never returns, but it will spawn another go routine for next song.

What do you think?

tramhao avatar May 21 '21 16:05 tramhao

Probably the problem is playingbar running for each song and didn't finish.

tramhao avatar May 21 '21 18:05 tramhao

I suspect playingbar is the problem. Try disable the playingbar, to see if the problem persists.

issadarkthing avatar May 24 '21 12:05 issadarkthing

Yes, after comment out the content inside playingbar.go:run(), everything seems fine. Probably something wrong inside here.

tramhao avatar May 25 '21 17:05 tramhao

I think I found the reason. playingbar.skip is never set to true, so the for loop is not ended. When playing, it's not a problem because for loop can be stopped.

tramhao avatar May 26 '21 16:05 tramhao

Fixed it for now. But I still have too many doubts about this run function.

  1. Data cannot be fed into go func(). For example, if I move full:=p.getFull before go func, the full length of status bar will not be updated when skip. It's just wired.
  2. Inside go func, I need access to many data outside, like subtitle or photo, and this create data race which I cannot fix. For int, I could use sync/atomic to avoid data race, but what can I do with pointer?
  3. The whole block is getting messy but I don't have any clue how to refactor playingbar. Do you have some ideas? Thanks.

tramhao avatar May 28 '21 05:05 tramhao