RAM usage

[ravibrock]

Hey – thanks for making this nice tool. It seems to work well for the most part, but one issue I've noticed is that the memory usage seems to balloon over time. I'll attach a screenshot below; the two deno processes that to the best of my knowledge are solely related to the Apple Music RPC were using close to half a gigabyte of memory. Immediately after restarting with brew services restart apple-music-discord-rpc they were back down to ~100 megabytes total. I wanted to open the issue in case it was the result of a memory leak.

Before restarting the process:

Immediately after restarting the process:

[NextFire]

I can't really see anything in the script that would cause this memory leak. The only object that continues to grow during execution is the cache, but even then it wouldn't eat up half a gigabyte (and as we restore it after a restart, it would then take up the same amount of memory). 😕

[ravibrock]

Thanks for the quick reply! That's weird. No worries if the bug can't be found. Not impossible that it's an issue with deno or my mac, but I can't imagine what it would be. Just in case, the logging info:

$ brew services info apple-music-discord-rpc
apple-music-discord-rpc (homebrew.mxcl.apple-music-discord-rpc)
Running: ✔
Loaded: ✔
Schedulable: ✘
User: root
PID: 69999

And the logfile was too large to attach (405k lines, ~30 megabytes) but this is the last 200k lines that I piped into their own file with tail. music-rpc.log

[NextFire]

Oh I didn't realized that there were two deno processes, one of which is running as root. You should only brew service start the thing once, without sudo (unless you are also running Discord as root...). These logs are just telling that the script cannot find the Discord socket (which is expected if the script is not running with the same user).

[ravibrock]

Ah, ok, thanks – I must have started one as root by accident. I've quit it now, but I just checked the working process and confirmed there's still the memory leak. Weird.

[Doggies-Galore]

I am also experiencing the app memory ballooning over time. I checked the source and it could have something to do with prescense being started and stopped. Perhaps a cache (my best guess is Album Artwork or its web requests) is being held somewhere/not cleared when presence is stopped.

[Avakining]

This may not be fixed, at least not entirely. This is shown running 0.11.1 on macOS 14.6.1

[NextFire]

😕 well let's keep this issue open then

[NextFire]

I tried to profile the script with deno run -A --unstable --inspect music-rpc.ts and Chrome devtools.

I ran the script for 10 minutes, with the default timeout set to 100ms. I profiled the execution in the memory tab multiple times and haven't noted anything remarkable.

What's strange though is that despite having a quite stable / very slowly growing heap size usage around ~30mb, the RAM usage in Activity Monitor went from ~30mb at the start to ~100mb at the end of my session.

(Memory tab in devtools)

(Activity Monitor)

So I'm really not sure if there is something wrong with the script. Maybe there are some shenanigans in Deno's internal memory usage and its garbage collection but that's probably out of my scope / ability to profile.

[daronspence]

Just chiming in that I've seen this behavior as well for months. Updated to deno v2 today, so I will keep an eye on it.