https://learn.microsoft.com/en-us/sysinternals/downloads/vmm... for an empty sublime text window gives me:

- 100MB 'image' (ie executable code; the executable itself plus all the OS libraries loaded.)

- 40MB heap

- 50MB "mapped file", mostly fonts opened with mmap() or the windows equivalent

- 45MB stack (each thread gets 2MB)

- 40MB "shareable" (no idea)

- 5MB "unusable" (appears to be address space that's not usable because of fragmentation, not actual RAM)

Generally if something's using a lot of RAM, the answer will be bitmaps of various sorts: draw buffers, decompressed textures, fonts, other graphical assets, and so on. In this case it's just allocated but not yet used heap+stacks, plus 100MB for the code.

Edit: I may be underestimating the role of binary code size. Visual Studio "devenv.exe" is sitting at 2GB of 'image'. Zoom is 500MB. VSCode is 300MB. Much of which are app-specific, not just Windows DLLs.

> I look at memory profiles of rnomal apps and often think "what is burning that memory".

As a corrolary to this: I look at CPU utilization graphs. Programs are completely idle. "What is burning all that CPU?!"

I remember using a computer with RAM measured in two-digit amounts of MiB. CPU measured in low hundreds of MHz. It felt just as fast -- sometimes faster -- as modern computers. Where is all of that extra RAM being used?! Where is all of that extra performance going?! There's no need for it!

Basically, the short answer is that most memory managers allocate more memory than a process needs, and then reuse it.

IE, in a JVM (Java) or dotnet (C#) process, the garbage collector allocates some memory from the operating system and keeps reusing it as it finds free memory and the program needs it.

These systems are built with the assumption that RAM is cheap and CPU cycles aren't, so they are highly optimized CPU-wise, but otherwise are RAM inefficient.

Completely agree, it would be very helpful to get even just a breakdown of what the ram is being used for. It's unfortunately a lot of work to instrument.

> sublime consumes 200mb. I have 4 text files open. What is it doing?

To add to what others have said: Depending on the platform a good amount will be the system itself, various buffers and caches. If you have a folder open in the side bar, Sublime Text will track and index all the files in there. There's also no limit to undo history that is kept in RAM.

There's also the possibility that that 200MB includes the subprocesses, meaning the two python plugin hosts and any processes your plugins spawn - which can include heavy LSP servers.

It's partly because there are layers of abstractions (frameworks, libraries / runtimes / VM, etc). Also, today's software often has other pressures, like development time, maintainability, security, robustness, accessibility, portability (OS / CPU architecture), etc. It's partly because the complexity / demand has increased.

https://waspdev.com/articles/2025-11-04/some-software-bloat-...

It is a matter of tooling.

Visual Studio runs the memory profiler in debug mode right from the start, it is the default configuration, you need to disable it.

https://learn.microsoft.com/en-us/visualstudio/profiling/mem...

200Mb for Sublime does not seem so bad when compared to Postman using 4Gb on my machine...

Part of the problem is that modern apps aren't really "one thing" anymore

> sublime consumes 200mb. I have 4 text files open. What is it doing?

Huh? Sublime Text? I have like 100 files open and it uses 12mb. Sublime is extremely lean.

Do you have plugins installed?