Hi all,
I think if the issue is with my code, it’s probably somewhere in a large class I wrote that is like 3.5k lines and probably not debuggable here. To my knowledge my class is not doing anything that should accumulate this much memory; it’s mostly array and list stuff, plus some methods for creating synths and setting their parameters with dictionaries. Since memory accumulates so gradually, I haven’t been able to pinpoint the precise source of the issue.
Has anyone else experienced large memory issues in SC? My technical + conceptual background on this aspect of programming in general is not strong, so I’d also appreciate suggestions for resources that I should look into to better understand what is happening under the hood.
Running Mac OS 26.2.
Best,
josh
April 20, 2026, 12:51am
2
I haven’t noticed this myself, but I would try taking the class out of your library and running without it for a day or two to see if the problem goes away. If it does, we know where to look next - if it doesn’t, then we can narrow it down to an SC problem.
/*www.realizedsound.net/josh
Next question: In Task Manager, which SC process is consuming excessive memory?
Based on your description, I’d have to bet that it’s scide.exe and not sclang.exe.
When you reboot the interpreter, the sclang.exe process exits. At that point, all of its memory should be released back to the OS. If sclang is consuming 30GB and it quits, and if at that point the memory is not released, that would be a Windows bug (which tbh is not out of the question) – although that’s extremely low probability, since memory bugs in an OS are severe by definition and would get a lot of scrutiny.
If the memory sticks around while the IDE is open, even without the interpreter running, and is released when quitting the IDE, the Occam’s Razor explanation would be that the IDE is leaking memory.
In that case, troubleshooting classes would not be useful.
Could you confirm that? After that, I guess file a bug report in the SC repository.
hjh
Hi Josh - I’ll try that soon. I will say though that I’m pretty close to positive it has something to do with the class. The issue slowly builds up while I am using my patches that incorporate the class, and I haven’t noticed it being an issue when I am working on patches where I don’t incorporate the class. That being said, I could have missed something, so I’ll give it a go.
Best,
Hi - working on Mac here. In Activity Monitor there are two processes for Supercollider: one for sclang and one that just says Contents/MacOS/Supercollider that I would assume is the IDE process. The sclang process takes up the usual ~200mb. Rebooting the interpreter definitely does not clear the memory use (for the IDE process).
I’d love to believe it’s not the class. I know logically it really shouldn’t have anything to do with it, but for some reason the memory use climbs specifically when I am using it. Even since posting this, as I’ve been working on my patch Supercollider has accumulated 6gb. That being said, it’s possible that I haven’t been paying enough attention to memory usage in situations where I’ve worked on other stuff, and all SuperCollider activity is causing it to climb.
manifesto-sauce:
working on Mac here
Ah, I saw unstable behavior and assumed Windows
Sclang is the process that’s responsible for running your class. If sclang isn’t chewing memory, then the probability of the problem arising from running your class is basically zero.
If it were me, I’d look into memory profiling on scide. I’m not familiar with those tools but I bet someone else here can give more details.
What is odd here is that if it were a general bug, a lot of users would be complaining. So there could be something environmental, or perhaps some broken characters in a file that causes it to spin out, or something.
Does Activity Monitor show whether the large memory use is resident in RAM or total allocation? In Linux, “RSS” (resident set size) measures actual RAM usage. It’s not unusual for a process to allocate more memory than is currently occupying RAM. (30GB is still a lot, though.)
hjh
prko
April 20, 2026, 4:48am
7
On my end (macOS 15.7.5, m1max), SC-IDE (3.15.0-dev) uses currently about 14 GB of memory:
Open Files and Ports
/myDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/PlugIns/imageformats/libqico.dylibmyDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/Frameworks/QtCore.framework/Versions/A/QtCore /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/C/com.apple.scriptmanager2.le.cache /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/C/com.apple.iconservices/store.indexmyDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/A/QtWebEngineCore /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/C/net.sourceforge.supercollider/com.apple.metal/32024/libraries.datamyDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/A/Resources/qtwebengine_resources.pakmyDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/A/Resources/qtwebengine_devtools_resources.pakmyDocs/Writings/Digital Sound Production/mixed/dev/SuperCollider.app/Contents/Frameworks/QtWebEngineCore.framework/Versions/A/Resources/qtwebengine_locales/en-GB.pak /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/T/SCIde_78719 /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/C/net.sourceforge.supercollider/com.apple.metal/16777235_530/functions.list /hdf9s2tx6kg7_yqv0bwqtlcm0000gn/C/net.sourceforge.supercollider/com.apple.metal/32024/libraries.list
Would reporting this information, including the details from Open Files and Ports, help identify the problem?
1 Like
Does Activity Monitor show whether the large memory use is resident in RAM or total allocation?
@jamshark70 Yes, that’s an important caveat!
In Windows, Process Explorer shows “Private Bytes” (= reserved memory space) and “Working Set” (= actual memory in use). Only looking at the former can be misleading.
@prko Are these 14 GB the actual memory in use? In the details, it mentions “Real Memory Size” is 512 MB.
The “Real Memory Size” looks fine, but it’s a bit weird that the IDE would need to reserve 14 GB.
I just had a look at two scide instances on my Windows 10 laptop that have been running non-stop for weeks:
Instance 1: Private Bytes: 370 MB, Working Set: 60 MB
One instance is SC 3.14, the other one is a recent development build.
For comparison, Chrome on my system right now has VSZ = 49.1 GB and multiple subprocesses each using 1.4 TB (!) – but RSS is a quite slim 501.9 MB.
My system has 16 GB physical RAM and it is not choking under this memory load – i.e., high virtual set readings may not actually mean anything (in terms of performance).
hjh
high virtual set readings may not actually mean anything (in terms of performance).
Yes, it only means that virtual addresses have been reserved over time for that amount of memory. Fortunately, 64-bit systems have an infinite virtual address space for all practical purposes.
prko
April 20, 2026, 2:22pm
11
I’m not sure. The 14 GB is just a rounded version of the 13.91 GB shown in the first screenshot.
