Lagg/Cpu hogging

[jordyvandomselaar]

OS: windows 10

Issue Descriptions: The app is hogging my cpu and laggs, I have a dual core running on 2,5 ghz and this app sometimes ends up 40% of it.

Steps to Reproduce: Open the app on a not-so-good laptop

[MarshallOfSound]

Can you run it in development mode and try running the CPU profiler on it. It should tell me what is using the cycles on your laptop. It's hard to tell on my hardware (I only have i7's) :cry:

[adampats]

I'm on OS X El Capitan 10.11.4 and I have the same issue - about 70% CPU usage on average across 3 processes (main one + helpers). CPU consumption seems to increase as I navigate around the app.

Running the latest commit.

[jordyvandomselaar]

How do I run it in dev mode?

[MarshallOfSound]

Clone the project

npm install
npm run build
npm start

@adampats If you're running latest can you run in dev mode and check out the JS profiler?

[steinerd]

@MarshallOfSound I wonder if there was a way to force Hardware Acceleration off the the GPMDP instance?

It might speed things up, or at least make them less resource hungry. Also, (at least on the Windows version) you could make a new check mark in the options that disables the constant re-writing of the %APPDATA%\Google Play Music Desktop Player\json_store\playback.json file. I/O like this in Windows will eat up CPU.

Food for thought.

[jostrander]

@Steinerd I'm not sure about the HW acceleration as I don't run windows, but the writes to disk are from having the playback API turned on, which already has a checkbox. Are you suggesting turning off the playback.json file optionally when the websocket API is active?

[steinerd]

I've turned it off and restarted the player... it still writes.

[steinerd]

I'll take a peek at the code and see if I can force it to run Hardware Acceleration disabled. The particles visualizer (via Album Art) may suffer, but I doubt people really use that. lol

[jostrander]

That could be the case:

https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/blob/master/src/main/utils/PlaybackAPI.js#L72

I suppose it's possible that you don't have the enableJSONApi key in your settings file, might have been an oversight. Can you check?

[steinerd]

LOOK AT THAT!

{
    "themeColor": "rgb(0, 188, 212)",
    "enableJSONApi": true,
    "nativeFrame": false,
    "enableWindowTitleInfo": false,
    "uuid": "f38a9596-3b4c-405a-a352-e22a09510cb2",
    "maximized": false,
    "position": [
        -1366,
        0
    ],
    "size": [
        1366,
        768
    ],
    "welcomed": "3.2.4",
    "lastPage": "https://play.google.com/music/listen#/album/Bz6suhmqgmokdsrrmiluu3nddte/The+Dear+Hunter/Act+IV%3A+Rebirth+in+Reprise",
    "theme": true,
    "playbackAPI": true,
    "checkedForOldVersion": true,
    "warnMinToTray": false,
    "mini-position": [
        678,
        485
    ],
    "mini-size": [
        310,
        310
    ]
}

I'll force the value and see if the CPU improves.

[jostrander]

wow, settings file looks like it's been through quite a few versions of GPMDP... heh. Do you mind saving yours and starting fresh to see if it will work correctly? I can't reproduce.

[jostrander]

Nevermind, I see the issue, there are duplicate keys, one called playbackAPI and one called enableJSONApi.. investigating further...

[MarshallOfSound]

Hold up people

The enableJsonApi setting is a secret setting. I.e. there is no check box for it

The check box is for the websocket API only. This should probably have its own check box as well

[jostrander]

Thanks @MarshallOfSound just noticed that.. I suppose the default for the secret key should be false? I don't see why it should be enabled by default.

[steinerd]

HAHAHAHA! Whoops. No problem, it took this issue thread for me to realize there was in-fact two settings. I would prefer to not have it write to the json file perpetually as my SSD would hate me for it and I can also confirm it helps with the CPU usage. Of the 4 processes that run on Windows only 1 of them has spiked and it was 5% usage... hovers around 3%. (5th Gen i7 though, may be different on a dual-core).

[MarshallOfSound]

@Steinerd @jostrander Can we move this convo to Gitter It's getting into a rather long issue thread

[adampats]

I ran the CPU profiler: link to raw file

Lots of activity on emit(), whatever that means (I'm not familiar with JS profile traces). It seems to be real bad (150% cpu) when scrolling through a list of some sort. Even when idle (not playing music or interacting with the UI), CPU is at ~30%. FYI, I'm running on an Early 2015 13" MBP with a 2.7GHz i5.

[MarshallOfSound]

@adampats The CPU time appears to be tracable back to this call https://github.com/MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-/blob/master/src/inject/generic/core/lyrics.js#L58

I think I just need to flip the logic here as sendSync is being called by Electron not us. Using asynchronous IPC will greatly improve performance here