Comment by GuB-42
2 days ago
Putting aside the fact that it is horribly bloated. Accurately measuring RAM usage is tricky, there are several measurements, and no "right" one.
It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.
The thing that the task manager doesn't tell you is whether or not these are shared components. It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.
In addition to the distinction between private and shared memory, there is also the distinction between actual RAM usage and and virtual memory. It is possible for a process to memory map a 100 GB file. If you look at the address space, it will take 100 GB more of virtual memory, even though it may be actually zero physical RAM, but it is not always zero either, the parts of the file that are currently accessed take up some space, which may later be reclaimed by the OS by committing the page to disk.
Even the most obvious "I do a big malloc()" kind of memory use is not that obvious, the OS can overcommit, put stuff into swap, use memory compression, etc... And it can do that even if the system is not overloaded, as to make more space for the disk cache for instance.
So seeing "1 GB" in the task manager is just a vague hint of how it may affect performance. And not all "task manager" tools give the same value for the same program (so Windows vs Mac may be misleading). "Process Explorer", a more advanced version of the Windows task manager can give a lot more details, with different values of memory usage depending on what you are looking at.
> The thing that the task manager doesn't tell you is whether or not these are shared components. It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.
It is the other way around, shared memory causes Task Manager to _underestimate_ memory usage. Task Manager's default views report the process private working set, no shared memory included. This means that 662MB is the _minimum_ amount of memory commit that would be released by ending the process.
> the OS can overcommit
Windows does not allow overcommit by default. It may compress or optimize memory allocations to reduce the physical working set, but the kernel will start failing memory allocations once physical + swap is exhausted regardless.
> It may be that the 662 MB used by the "Renderer" is shared between many Windows components
From the screenshot in the article, this is the memory usage of the Renderer process spawned by the Weather App. I find it very unlikely that some other app (say, the Copilot app) can then piggyback on Weather Renderer process. Do you have a source for this?
> killing that Weather app may not reclaim as much space
Closing the weather app on my PC does in fact kill all child processes and frees up around 1GB of committed RAM. Are you not seeing the same?
I am not on Windows 11 so I can't really tell. And even if I did, I may be in a different situation than yours, we may not be running the same apps so what is shared can be different.
As for the "piggybacking" it is not really piggybacking, it is how shared libraries work (emphasis on the "shared"), aka. DLLs on Windows. For instance, if 2 to processes load "library.dll", it will be only loaded once, and the read-only parts of the library will be shared between the processes and it is one of the big advantages of shared libraries over static linking. A major part of the Weather app bloat comes from the browser engine it comes with, something many apps do today, and it would be reasonable to think that 2 apps using a browser engines have components in common.
Anyway, if you run Process Explorer and check the weather app process, it will tell you which is which.
This, by the way is a big reason why modern apps are often so bloated. The real problem is not just that so many apps are using browser engines or other huge dependency chains, it is that they all ship with their own version instead of using what is available on the system, so you have 10 different browser engines loaded in RAM even though a single one would be enough. Traditional Linux distros do it right, but now we have containerized application that break sharing. I understand the convenience, as you don't have to deal with shared library update that break the app, but the cost in both RAM and storage space is significant.
Additional constraint here: it's not just browser version. Processes have to refer to the same disk location for sharing to work. Given that each ships the full set of dependencies disk location will never match (except for their own child processes).
The weather app itself and the framework it runs on are the same thing when talking about resource usage.
Not when the "framework" resources are shared between multiple apps using the same framework. This doesn't seem to be the case here though.
It used to be shared, but vast amount of insidious attacks like Heartbleed forced web engine developers to force strict isolation between everything
Only working memory (the writable part) has to be isolated between users of a shared component. Modern OSes and MMUs do it well. 2 processes using a shared OpenSSL library won't be able to peek at each other. At best, one process may be able to see that the other is using the library by doing some performance analysis, but working data never crosses border (barring a hardware or kernel-level bug).
It is not a problem of data going across process borders, it is about guaranteeing that each dependency is at the version for which the app has been tested with. From a security standpoint, it has pros and cons. The pro is that it is easier to qualify, and it makes the app less susceptible to system-level attacks and regressions. The con is that should a vulnerability be discovered in a dependency, it won't be fixed by a system update, you have to integrate the fix yourself and make a new release.
Separate Renderer and GPU Process is just typical webview2/electron
> It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.
Got a bit confused by this, because nowhere in the article are the words "Renderer" or "GPU". Regardless - all processes that comprise the app are the app, not just the parent process.
When I run it locally and check in procexp it has 8 webview subprocesses and all together it's using similar if not higher levels of memory than claimed in the article. Private Bytes is over a GB in total. I expect the webview processes are sharing memory for DLLs though.
> It may be that the 662 MB used by the "Renderer" is shared between many Windows components, so killing that Weather app may not reclaim as much space as you may hope, instead, it would require killing every user of the component, some may be core system apps.
Bet one’s ass that “Renderer” sub-process is embed browser engine allocating working memory for rendering of web app page layout.
> It is clear from the article that what eats up so much RAM is not the weather app itself but the framework it runs on. There is a "Renderer", a "GPU Process",... eating most of it.
You say tomato we say tomahto
At the end of the day bloated app is a bloated app its consequences are the same.
10 apss using 100mb each plus 600mb shared use less ram than 10 apps using 200mb each.
Still goddamn bloat. No amount of sharing will change that.
Tis not shared
> the 662 MB used by the "Renderer" is shared between many Windows components
Fine, shutdown the weather and stock ticker apps.