3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.
4. Delete the in-box Weather app icon.
Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.
(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)
> According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework.
I wonder how this approach is having such an high reduction in memory usage compared to what’s stated in the article. I would assume both use the exact same WebView here.
The only explanation here that I can think of would be that the “Add an application” starts it under an existing Edge process which shares it’s memory instead of completely isolated.
Yes, using an already-running Edge instance saves a bunch of memory. Also, this approach has the advantage of allowing all of your browser extensions to modify your Web-App experience. WebView2 doesn't relay Edge extensions.
> According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.
If you have Edge or Chrome open (or anything else that similarly uses Chromium) then the incremental increase in RAM usage from the Weather app is likely much smaller than the headline 1GB.
My gaming PC that I built in January 2006 that IIRC I used to simultaneously run Battlefield 2, Trillian, Xfire, Thunderbird, and Winamp with a 1680x1050 monitor had 1 GB of total system RAM.
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?
> 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.
As time goes on, I become more and more convinced that OSes need some sort of OS level GC pool which all GCed languages play in rather than having the language runtime provide the GC.
A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.
This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.
> A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
There’s very minimal state for a weather app. You should be able to sweep the whole thing pretty fast. You could probably statically allocate most of that state.
The ram usage in this case is an order of magnitude lower if you install ublock in edge, as other comments have noted. Why would a system level GC affect wasteful adtech?
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
What's worse is that the previous version of the same Weather app was fully native on Windows 10. Why would you take a perfectly working app and downgrade it like this?
This took me down a rabbit whole. Why can a simple single purpose app not be just a couple megabytes if not less? The popular options are electron 100MB+, or embedding python3 in your executable which is at least 40MB.
But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.
Pictures and frame buffers. If you're running fullscreen at 4k, you're probably gonna take two roughly 3840x2160x3 byte frame buffers for the window. Your designers want a background image which moves as you scroll in some parallax style; that's over 3840x2160x3 bytes more for the pixel buffer backing the image layer. And let's say roughly 50% of your screen is text with subpixel (aka full color) anti aliasing; that means another 3840x2160x3x0.5 bytes for the pre rendered text.
3840x2160x3x3.5. That's 87MB, in pixel data only. And it's a very minimal example; for the parallax image, you're gonna want the image to be significantly taller than the window; you're gonna want a ton of smaller (tho still high DPI) images for icons; a few different font atlases for different font faces you've loaded at once; maybe pre rendered pixel buffers for all sorts of UI components; etc.
And lord help you if your designers want any part of this to be animated.
(I'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory. Though applications may wanna store CPU-side copies as well for various reasons.)
> i'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory
Yeah this is irrelevant here, windows doesn't share both in 99 of the case.
Good point. Though 4k image assets mean more that they look in 4k, not that their size is 4k. It might not be 87mb, but still way more than the couple mb I suggested.
??? Fast and loose is an understatement, at best it's a view from a rendering engineer that thinks all software acquires a DXGI swap chain and handles buffering itself, but it's flat out wrong and over two times too high at the very least.
* Not every app is full screen (especially not a weather widget.)
* Very few people actually have a 4K display. 1080p and 1440p cover over 75% of users already.
* You do not allocate a separate buffer for the main content and the parallax, applying a different transform does not need a dedicated buffer, just something the size of your asset. It can be a 640x480 upscaled asset for all you care.
* You also don't allocate a dedicated buffer for text rendering/hinting. Your text rendering engine keeps a texture atlas in a buffer which is eventually maaaaaybe reach a 4k texture if you display a TON of various glyphs, realistically they won't. DirectWrite will also share this atlas with other executables unless you explicitly ask for isolation.
* On windows, you write to DWM, which keeps a single buffet for all your windows. Every window does not pay that memory price. I'm pretty sure most compositors do something similar.
A lot of these applications run in Electron or similar libraries where a whole new browser instance, with all its overhead, is stood up for each application. The simplest answer is we need to stop trying to use web technologies as a one-size-fits-all GUI toolkit.
Do all visual aspects of a weather app need to be loaded at once? Is the cost penalty loading a hundred kilobytes per image from disk really unacceptable?
It can, but you have to know what you’re doing and you have to know it very well.
Looking at the opposite extreme, the guy that originally wrote the windows task manager (the thing that popped put when you pressed ctrl+alt+canc) posted a video about cloning the windows basic text editor in a 3kb binary: https://youtu.be/OG91c7xsNMc
Microsoft absolutely doesn't need it, but I'm guessing the weather app team (or the core filler apps team or whatever team is responsible for it) needs it to juice a metric to make some middle manager happy.
And it makes the middle manager happy because it lets that middle manager report better numbers to their superiors again.
Etc.
It's why all large dysfunctional organisations do self destructive stuff like this.
That’s the goal of every publicly-traded corporation in a mature market. Wall Street demands ever-increasing returns and they can’t grow their customer base much so cost-cutting and fleecing existing customers are the only levers to pull.
250 MB is exactly the sort of bloat you'd expect from this sort of daft web-browser-wrapper application, and Apple get it there. 1.2 GB, on the other hand, is 5x as much, and completely insane even when you start off with daft as your starting point.
I use Linux now, so you're on your own if there are issues. It might require some windows library to be installed but I don't recall. I ran it for a long while on win11.
My entire kde "plasmashell" which includes my wallpaper and the various widgets installed (including a weather widget) uses 560MB for a screen with 5120x1440 pixels.
I built a weather app for myself fetching ECMWF ensemble forecasts for my home location. Running the service is 60mb plus data 39mb and another 2mb for the spaghetti charts showing temperature, clouds, precip, wind over 10 days. What do I need to do to fill the other 900mb?
The article now says for me "By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions."... which is not exactly the same wording.
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
After seeing https://news.ycombinator.com/item?id=49226923 show up here, I'm now hoping someone will vibe-code a nearly identical-looking native app that takes a few orders of magnitude less RAM.
Personally I just use my government's website when I need to check the forecast.
I’ve used Wego [0] for roughly a decade. It’s been good enough for me.
Six years in, I had to edit the configuration file once (to switch weather backends because the default backend shut down). In January, it’ll be 10 years.
RAM consumption has gotten crazy over the past couple of years. Consumers need to start calling software devs out for this, especially when there's such a severe shortage of RAM.
They can, but they won’t. Microsoft is run by the most cutthroat sycophants you could possibly imagine. That money you mentioned is going to those aforementioned sycophants and shareholders.
The author doesn't need to know the difference because the task manager is accurate by default. I can still offer you some reassurance:
- The Windows task manager's memory column is the private working set which is the actual memory used by the application minus shared memory (but only shared memory that is currently shared with other processes, not merely marked shared. I.E. it's similar to RES - SHR on Linux but it's more accurate)
- Windows doesn't overcommit memory. Memory that is reserved but unused (not touching all pages) by the app is truly wasted. I mention this because in your other comment you make it clear that you think this is happening. But Windows isn't Linux.
I’m not sure if you mean a good look for the process or for the author but paging space is just saying “gimme a gigabyte” like saying “gimme a plate” is at a barbecue. The resources themselves aren’t being used at that point.
This article seems to be underestimating how much RAM a weather app should take. A well thought-out, native Weather app wouldn't take more than 100 mb of RAM.
Back in my day systems used to be a lot simpler too. These “back in my mind” comparisons show a clear lack of understanding of the subject matter. 1996 apps are not the same as 2026 apps. Expectations are different. Design languages are different. Even the UX is entirely different.
1GB is clearly overkill, no question. But ~100MB to ~300MB is perfectly reasonable and you know it.
Mostly rendering. A bunch of images, text, UI elements. On a modern high resolution display it adds up quite quickly. You can surely cut it down a bit, but 100MB isn't absurd.
I think this depends on your location, because in some places you really want to view a radar map. "Rain in $CITY" is practically useless for me. Still, the (static?) map in the depicted app shouldn't take 1GB.
My favorite '90s weather app was WetSock. The installer was 1.5MB, though I don't recall the RAM usage. It showed a sunny/cloudy/etc. icon in the system tray, with the temperature in a tooltip:
They also have a nice API where you can pull the raw weather data and fancy it up any way you like graphically. Great for building your own entirely custom weather widget for your desktop, webpage, app, or whatever. :)
Well it's comparing it to apple's weather app, which is a fair comparison I suppose. 100mb still sounds like at least an order of magnitude too high to me though.
No, because you have to manage communication between different teams on "how" and "what" about the single browser, much easier to let every team do their "best" without any external interference
Yesterday I was running :
NixOS, mango window manager, 5 instances of ghostty, 2 of those running fresh terminal editor, firefox with 5 tabs and I was at 2.37gb of RAM.
Shame, because it's genuinely a great map - ahem, optimizations aside.
I remember giving the app a second chance - after assuming it to be bloatware next to all the other default apps that came with Windows - but after seeing it redeem itself in benchmarks[1], I gave it a shot and quite like it. The iOS app was too rubbish to bother with, though.
I'm curious what could options there are for decent predictions. Especially with Dark Sky never having been much of an option for Europe. I see some of the people behind it have a new subscription-based iOS app to try, though: https://acmeweather.com/app.
Do people have any desktop weather apps that strike a nice balance between decent code and actually useful predictions? Future weather's likely to be anything but boring, unfortunately.
I am using AI to rewrite every proprietary driver/companion soft I had still running on my Mac system.I am using 5/10% of the original application's RAM.I am getting more features.My background RAM usage halved after converting many of them to my own versions.
I wonder if this is a fair calculation including the fact that multiple WebView apps should be sharing the same libraries in memory.
If you pay 0.5-1GB to load the edge/chromium libraries but that memory is amortized over N different apps the user is likely to run, then the ”1GB for the weather app” is an unlikely worst case.
I seriously wonder if the recent migrations between languages mande by major projects leveraging SOTA LLMs have started a new trend of a) making native apps more common, as opposed to Electron and stuff b) will help to optimize existing apps and remove the bloat.
The alternative is, of course, that most apps will end up being bloated even more specifically because of how we'll slowly transition into developing using LLMs only.
All the comments excusing the RAM usage "because high-resolution screens require pixels" are missing the fact that there's this thing called GPU memory. Which is where pixels data should be. There's no way you need to store fullscreen 4K images for a weather app on anything else than the GPU: use scalable icons, render them on the GPU. No need to use actual RAM: the GPUs have had their own RAM since times immemorial and GPU rendering is a thing too.
PC games were the last reason why I still used windows. Now that Proton works wonders in Linux, I hope I don’t need to ever come back again. Great times with 98, xp and win7 that were snappy, easy to install and with no slop
i mean webKit never handle viewport well when compare to firefox or chrome. it's willing to materialize a 10000*10000 texture when firefox and chrome will think that is too dumb and only load the visible part. It's not a good target if you want to compare windows and mac software quality.
Super interesting; it's been exactly the opposite in my experience. MacOS/iOS users put up with whatever Apple is telling them they should love - Liquid Glass, right? App Store restrictions, right? Lousy AI, right? - whether it's true or not. Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago.
As for Windows, I like living in cities. If you live in a city long enough - at least through a couple of major macroeconomic cycles - you'll see it improve in some ways and some neighborhoods, get worse in some ways and some neighborhoods, then improve again, etc. Cycles. Windows found itself in a downturn the last few years, primarily due to the org structure that took Windows shell away from people who could really look after it, and, yes some of those execs have earned my permanent scorn, like a bad local politician would. Now there's a focused team making that neighborhood better. I'm here for the whole ride.
I'll use Linux on computers I don't have to log into very much, so I don't have that UX problem (case-sensitive command lines? Seriously? The 1970's called...). I'll never move to MacOS City; it's like wanting to live in The Villages. Manicured lawns with no soul.
So I live in Windows Town, it's not perfect, no city is, but it's always changing, always moving, going through ups and downs, and now it has a new "city council" that's making changes for the better. And I'm expert enough to make it great for me, and avoid the "neighborhoods" that suck.
This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:
1. Install uBlock Origin in Edge.
2. Start Edge, browse to MSN Weather.
3. Click the "Add an Application" button in the address bar so I have a Start Menu icon for the page.
4. Delete the in-box Weather app icon.
Now I have the same weather site, no ads, running in about 130MB of RAM.
Enjoy your choice of operating system. Live where you want. Sometimes your city has problems. Move if you want, but don't think you've permanently solved your UX issues if you do, you've just swapped them for different ones.
Liquid Glass needs a lot of cleaning up but it’s fine. App Store restrictions mean very little for iOS users in general and next to nothing for Mac users. Lousy AI also means little to nothing on Mac and earns at max a shrug on iOS—you even have a handy little button to disable all Apple Intelligence shenanigans altogether which is something no Windows user can easily do with Copilot.
No, Apple users are most definitely not having to deal with the same level of bullshit Microsoft’s users are. And it’s not even close.
>> Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago
I put in the exact same amount of effort to install a Linux distro on my laptop that I would have to install Windows.
1. Download the ISO
2. Write to a USB drive
3. Reboot
4. Run the installer.
5. ???
6. Profit
And all for an experience with way less bloat, none of the bundled spyware, more consistent UI design (depending on which desktop you're using), and better perceived performance.
>>This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:
This is still a web app, it doesn't solve the problem of MS being too lazy or cheap to make real desktop apps for things. I mean this is the same company who thought taking the Start Menu of all things and re-making it with web crap was a good idea.
I mean, if the only things you can name are Liquid Glass, App Store and not-so-intelligent AI then it seems like Apple users are actually doing quite well?
It's impossible for every idea to be a hit. Liquid Glass was a miss and they backtracked on some changes and fixed some issues that people were vocal about.
...you know, I keep reading all this stuff about memory prices, and it does suck, but memory is still much cheaper per gigabyte than it was ~15 years ago.
Which matters because the things most consumers are doing on their computers haven't changed in the past 15 years. We browse the web, edit photos, message friends, and so on. AI generally runs on remote servers anyway.
For years, everyone kept saying it was fine that Electron used gigabytes of memory, because on modern PCs memory was plentiful anyway. Well, it's not plentiful anymore! Maybe it's time software developers actually used resources efficiently?
But it's literally not cheaper than it was ~15 years ago? Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.
>Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.
...when looking at nominal prices (ie. not adjusted for inflation). If you adjust for that the furthest back you can go to get that price is 2011. What's more is that because RAM prices are subject to boom and bust cycles, that price has also been reached in 2015. So just by tweaking two parameters we went from 19 years (2007) to 11 years (2015).
We had modern programming toolkits that traded some efficiency for ease of use 20 years ago, along with GPU compositing for maximum smoothness. And that's when Vista came out requiring a whole 1GB to run properly. And other than doubling for 64GB that didn't change through 7, 8, 8.1, 10.
Electron was never a great idea but more and more basic things keep moving to it and the result is a disaster. When you use it for several little things at once it turns from annoying waste into massive waste.
I likely unfairly judge (at a high-level) code security based on how much system resources applications waste. If your app, or OS uses that much resource to perform simple operations then you clearly lack understanding of what the code is doing. How then can I expect it to be secure?
I don’t know if this is sarcastic. A lot of bloat in GUI apps is because they are built as websites with a bloated front end, dependencies, custom fonts plus the binary compiled code and the decompressed images cached by the browser.
> Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.
Easy workaround for this:
1. Install uBlock Origin in Edge.
2. Start Edge, browse to MSN Weather.
3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.
4. Delete the in-box Weather app icon.
Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.
(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)
1. install ublock origin on Firefox.
not even being annoying, edge is removing manifest v2 very soon, breaking proper ad blocks just like chrome
I don't know if I'd say that's gonna break "proper ad blocks".
UBO Lite (the MV3 version of UBO) seems to work just fine in my experience, at the core function of being an ad blocker,
2 replies →
> According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework.
I wonder how this approach is having such an high reduction in memory usage compared to what’s stated in the article. I would assume both use the exact same WebView here.
The only explanation here that I can think of would be that the “Add an application” starts it under an existing Edge process which shares it’s memory instead of completely isolated.
Yes, using an already-running Edge instance saves a bunch of memory. Also, this approach has the advantage of allowing all of your browser extensions to modify your Web-App experience. WebView2 doesn't relay Edge extensions.
The weather app isn't a native app either:
> According to Windows Latest, the high memory consumption is due to the fact that Weather is not a fully native Windows application. Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.
If you have Edge or Chrome open (or anything else that similarly uses Chromium) then the incremental increase in RAM usage from the Weather app is likely much smaller than the headline 1GB.
waiting for a quick simple straight forward tool on github that takes care of this... Anyone?
https://github.com/pbatard/rufus/releases
or
https://unetbootin.github.io/#distros
My gaming PC that I built in January 2006 that IIRC I used to simultaneously run Battlefield 2, Trillian, Xfire, Thunderbird, and Winamp with a 1680x1050 monitor had 1 GB of total system RAM.
Fun fact, one of the XFire cofounders won Carmack's Ferrari at a Quake Tourney:
https://en.wikipedia.org/wiki/Dennis_Fong#/media/File:John_C...
take me back
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?
> 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.
> the 662 MB used by the "Renderer" is shared between many Windows components
Fine, shutdown the weather and stock ticker apps.
As time goes on, I become more and more convinced that OSes need some sort of OS level GC pool which all GCed languages play in rather than having the language runtime provide the GC.
A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.
This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.
Which is what OSes implemented in system languages with automatic memory management usually do, it is an OS service.
Oberon example,
https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
Active Oberon example,
https://github.com/btreut/a2/blob/master/source/GarbageColle...
Bare metal Java, Go, .NET, Erlang, OCaml,... with bare metal deployments naturally have the runtime take the OS role.
This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal.
Then C# came and said "we can't use it, we have different needs". So did Go.
> A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.
There’s very minimal state for a weather app. You should be able to sweep the whole thing pretty fast. You could probably statically allocate most of that state.
> There’s very minimal state for a weather app.
Except when it uses some kind of browser engine to render its UI?
The ram usage in this case is an order of magnitude lower if you install ublock in edge, as other comments have noted. Why would a system level GC affect wasteful adtech?
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
What's worse is that the previous version of the same Weather app was fully native on Windows 10. Why would you take a perfectly working app and downgrade it like this?
Well, this is Microsoft and Windows; it would be weird if it got better.
This took me down a rabbit whole. Why can a simple single purpose app not be just a couple megabytes if not less? The popular options are electron 100MB+, or embedding python3 in your executable which is at least 40MB.
But if you build it natively, you should have all of Microsoft tools at your disposition, dlls and such. In theory, this should allow you to make a 1 mb app or less. But in practice, it's the worse option.
Pictures and frame buffers. If you're running fullscreen at 4k, you're probably gonna take two roughly 3840x2160x3 byte frame buffers for the window. Your designers want a background image which moves as you scroll in some parallax style; that's over 3840x2160x3 bytes more for the pixel buffer backing the image layer. And let's say roughly 50% of your screen is text with subpixel (aka full color) anti aliasing; that means another 3840x2160x3x0.5 bytes for the pre rendered text.
3840x2160x3x3.5. That's 87MB, in pixel data only. And it's a very minimal example; for the parallax image, you're gonna want the image to be significantly taller than the window; you're gonna want a ton of smaller (tho still high DPI) images for icons; a few different font atlases for different font faces you've loaded at once; maybe pre rendered pixel buffers for all sorts of UI components; etc.
And lord help you if your designers want any part of this to be animated.
(I'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory. Though applications may wanna store CPU-side copies as well for various reasons.)
>Your designers want
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
8 replies →
> i'm playing a bit fast and loose with what lives on the GPU and what lives on the CPU here. On many systems, they share a memory pool anyway. But on systems with discrete GPUs, most of this is gonna be video memory
Yeah this is irrelevant here, windows doesn't share both in 99 of the case.
2 replies →
Good point. Though 4k image assets mean more that they look in 4k, not that their size is 4k. It might not be 87mb, but still way more than the couple mb I suggested.
??? Fast and loose is an understatement, at best it's a view from a rendering engineer that thinks all software acquires a DXGI swap chain and handles buffering itself, but it's flat out wrong and over two times too high at the very least.
* Not every app is full screen (especially not a weather widget.)
* Very few people actually have a 4K display. 1080p and 1440p cover over 75% of users already.
* You do not allocate a separate buffer for the main content and the parallax, applying a different transform does not need a dedicated buffer, just something the size of your asset. It can be a 640x480 upscaled asset for all you care.
* You also don't allocate a dedicated buffer for text rendering/hinting. Your text rendering engine keeps a texture atlas in a buffer which is eventually maaaaaybe reach a 4k texture if you display a TON of various glyphs, realistically they won't. DirectWrite will also share this atlas with other executables unless you explicitly ask for isolation.
* On windows, you write to DWM, which keeps a single buffet for all your windows. Every window does not pay that memory price. I'm pretty sure most compositors do something similar.
1 reply →
A lot of these applications run in Electron or similar libraries where a whole new browser instance, with all its overhead, is stood up for each application. The simplest answer is we need to stop trying to use web technologies as a one-size-fits-all GUI toolkit.
> This took me down a rabbit whole.
The rabbit was too hungry to even stop to chew you?
Haha, and it's far too late to edit!
Beware the rabid rabbit and don't let your whole near his hole . . .
The visual assets alone will be tens of megabytes.
Why, though? You need some icons and some map imagery, not 4K texture maps
1 reply →
Should be able to get by with using system graphics
Do all visual aspects of a weather app need to be loaded at once? Is the cost penalty loading a hundred kilobytes per image from disk really unacceptable?
2 replies →
For a weather app, you should be able to get by with a couple base vectors you modify based on conditions.
13 replies →
It can, but you have to know what you’re doing and you have to know it very well.
Looking at the opposite extreme, the guy that originally wrote the windows task manager (the thing that popped put when you pressed ctrl+alt+canc) posted a video about cloning the windows basic text editor in a 3kb binary: https://youtu.be/OG91c7xsNMc
Needless to say, the guy knows what he’s doing.
And it also ads on it.
Really Microsoft? Do you really need all the ads revenue from the weather app?
What’s next? Ads on the start menu?
Microsoft absolutely doesn't need it, but I'm guessing the weather app team (or the core filler apps team or whatever team is responsible for it) needs it to juice a metric to make some middle manager happy.
And it makes the middle manager happy because it lets that middle manager report better numbers to their superiors again.
Etc.
It's why all large dysfunctional organisations do self destructive stuff like this.
“What value are you bringing to the company?” translates to “if you’re not printing money, you lose your job.”
5 replies →
> What’s next? Ads on the start menu?
They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...
Patent was being sarcastic. Everybody heard about (or had the displeasure of seeing) those ads.
Don't they even had it earlyer and even let the DNS expire, so someone else could spam the startmenu?
They do. Never forget, Microsoft's goal is to squeeze as much money from you as possible.
That’s the goal of every publicly-traded corporation in a mature market. Wall Street demands ever-increasing returns and they can’t grow their customer base much so cost-cutting and fleecing existing customers are the only levers to pull.
> By comparison, Apple's native Weather app on macOS reportedly uses less than 250 MB of RAM
That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?
It’s an equivalent app to make a comparison with, one from an OS company.
But yeah, I still remember when a weather app would take 10 MB and I was complaining (1999)
250 MB is exactly the sort of bloat you'd expect from this sort of daft web-browser-wrapper application, and Apple get it there. 1.2 GB, on the other hand, is 5x as much, and completely insane even when you start off with daft as your starting point.
4 replies →
I prompted my own windows taskbar weather app in rust with radar and forecasts and it's 233 kB.
https://github.com/derac/WeatherTray
I use Linux now, so you're on your own if there are issues. It might require some windows library to be installed but I don't recall. I ran it for a long while on win11.
4 replies →
10MB to tell me the weather from a remote server...
Let's remember that the sprawling world of Legend of Zelda SNES (a Link to the Past), including all graphics, music, code and dialogue was 1MB.
7 replies →
10 MB is ridiculously overbloated. 1 MB or something in that vicinity should be more like it.
48 replies →
My entire kde "plasmashell" which includes my wallpaper and the various widgets installed (including a weather widget) uses 560MB for a screen with 5120x1440 pixels.
That's still 26x more than the size of the display buffer, I would never settle for such bloat /s
https://github.com/dglent/meteo-qt
It is using 122.7 MB at present.
I built a weather app for myself fetching ECMWF ensemble forecasts for my home location. Running the service is 60mb plus data 39mb and another 2mb for the spaghetti charts showing temperature, clouds, precip, wind over 10 days. What do I need to do to fill the other 900mb?
Run those things as an electron app? Add on analytics, location tracking and data exfil and you'll be fairly close
The article now says for me "By comparison, Apple's native Weather app on macOS uses roughly five times less memory under similar conditions."... which is not exactly the same wording.
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
The most lightweight solution I can think of is:
That's basically my weather app. Though, I made it fancy at 7 lines of bash which takes location arguments and pipes into jq for display.
[dead]
After seeing https://news.ycombinator.com/item?id=49226923 show up here, I'm now hoping someone will vibe-code a nearly identical-looking native app that takes a few orders of magnitude less RAM.
Personally I just use my government's website when I need to check the forecast.
I’ve used Wego [0] for roughly a decade. It’s been good enough for me.
Six years in, I had to edit the configuration file once (to switch weather backends because the default backend shut down). In January, it’ll be 10 years.
[0]: https://github.com/schachmat/wego
Why does everything turn into a browser
Because Jamie Zawinski was right and also wrong. Everything evolves into a browser, which, yes, can also read email.
RAM consumption has gotten crazy over the past couple of years. Consumers need to start calling software devs out for this, especially when there's such a severe shortage of RAM.
They could ask AI to refactor and debloat, since they can't be bothered with it because the incentives don't seem to align.
Last decade has been the worst, not even worth it for the eye candy like before.
Please, Microsoft, PLEASE ! You can do BETTER ! Stop acting like an internship for every single feature you add ! Where's the money going ?
They can, but they won’t. Microsoft is run by the most cutthroat sycophants you could possibly imagine. That money you mentioned is going to those aforementioned sycophants and shareholders.
But will the earn more money by offering a better weather app?
I would like to be assured that the author knows the difference between actual memory and setting aside paging space.
The author doesn't need to know the difference because the task manager is accurate by default. I can still offer you some reassurance:
- The Windows task manager's memory column is the private working set which is the actual memory used by the application minus shared memory (but only shared memory that is currently shared with other processes, not merely marked shared. I.E. it's similar to RES - SHR on Linux but it's more accurate)
- Windows doesn't overcommit memory. Memory that is reserved but unused (not touching all pages) by the app is truly wasted. I mention this because in your other comment you make it clear that you think this is happening. But Windows isn't Linux.
That still isn't a good look.
I’m not sure if you mean a good look for the process or for the author but paging space is just saying “gimme a gigabyte” like saying “gimme a plate” is at a barbecue. The resources themselves aren’t being used at that point.
2 replies →
This article seems to be underestimating how much RAM a weather app should take. A well thought-out, native Weather app wouldn't take more than 100 mb of RAM.
This has strong "How much could a banana cost? 10 dollars?" vibes.
Back in my day 100MB was all you had for all your compute, and somehow programs still ran.
Back in my days, I had to remove the mouse driver from autoexec so that microprose grand pirx had 600kb of ram to start
3 replies →
When RAM was $100 per MB that would be $10,000. You can do a weather app in much less provided you use native code.
LumiWeather for AmigaOS runs on 2 MB RAM.
2 replies →
> Back in my day
Back in my day systems used to be a lot simpler too. These “back in my mind” comparisons show a clear lack of understanding of the subject matter. 1996 apps are not the same as 2026 apps. Expectations are different. Design languages are different. Even the UX is entirely different.
1GB is clearly overkill, no question. But ~100MB to ~300MB is perfectly reasonable and you know it.
3 replies →
What is the weather app doing that it requires 100MB? For such a simple application, that seems excessive.
Mostly rendering. A bunch of images, text, UI elements. On a modern high resolution display it adds up quite quickly. You can surely cut it down a bit, but 100MB isn't absurd.
10 replies →
I think this depends on your location, because in some places you really want to view a radar map. "Rain in $CITY" is practically useless for me. Still, the (static?) map in the depicted app shouldn't take 1GB.
My favorite '90s weather app was WetSock. The installer was 1.5MB, though I don't recall the RAM usage. It showed a sunny/cloudy/etc. icon in the system tray, with the temperature in a tooltip:
https://web.archive.org/web/20010210023051/http://www.softse...
https://web.archive.org/web/20070210195451/http://www.locutu...
I am pretty sure xfce4 weather plugin takes a lot less.
Looks like about 30 MiB with a quick test.
You don't need anything more than https://wttr.in/ even with all the fancy terminal graphics.
They also have a nice API where you can pull the raw weather data and fancy it up any way you like graphically. Great for building your own entirely custom weather widget for your desktop, webpage, app, or whatever. :)
Why would I like to know the weather in some other city?
3 replies →
Well it's comparing it to apple's weather app, which is a fair comparison I suppose. 100mb still sounds like at least an order of magnitude too high to me though.
It's just msn weather page. Can't they use one single browser for all their apps instead of one per app?
No, because you have to manage communication between different teams on "how" and "what" about the single browser, much easier to let every team do their "best" without any external interference
Yesterday I was running : NixOS, mango window manager, 5 instances of ghostty, 2 of those running fresh terminal editor, firefox with 5 tabs and I was at 2.37gb of RAM.
For comparison, the GNOME Weather app takes 80MB.
Shame, because it's genuinely a great map - ahem, optimizations aside.
I remember giving the app a second chance - after assuming it to be bloatware next to all the other default apps that came with Windows - but after seeing it redeem itself in benchmarks[1], I gave it a shot and quite like it. The iOS app was too rubbish to bother with, though.
I'm curious what could options there are for decent predictions. Especially with Dark Sky never having been much of an option for Europe. I see some of the people behind it have a new subscription-based iOS app to try, though: https://acmeweather.com/app.
Do people have any desktop weather apps that strike a nice balance between decent code and actually useful predictions? Future weather's likely to be anything but boring, unfortunately.
[1]: https://forecastwatch.com/awards/2026/
My country's agency for weather and water mgmt has consistently the best 48h forecast. Try looking for an equivalent in yours.
Reminds me this https://waspdev.com/static/images/2025-11-04/bloat.webp
I am using AI to rewrite every proprietary driver/companion soft I had still running on my Mac system.I am using 5/10% of the original application's RAM.I am getting more features.My background RAM usage halved after converting many of them to my own versions.
I wonder if this is a fair calculation including the fact that multiple WebView apps should be sharing the same libraries in memory.
If you pay 0.5-1GB to load the edge/chromium libraries but that memory is amortized over N different apps the user is likely to run, then the ”1GB for the weather app” is an unlikely worst case.
This is what happens when you start a separate instance of Chromium everywhere.
Apple Weather app can jump to 1GB on a mac if you click around a little with the wind gust direction particle effect in the map
I seriously wonder if the recent migrations between languages mande by major projects leveraging SOTA LLMs have started a new trend of a) making native apps more common, as opposed to Electron and stuff b) will help to optimize existing apps and remove the bloat.
The alternative is, of course, that most apps will end up being bloated even more specifically because of how we'll slowly transition into developing using LLMs only.
All the comments excusing the RAM usage "because high-resolution screens require pixels" are missing the fact that there's this thing called GPU memory. Which is where pixels data should be. There's no way you need to store fullscreen 4K images for a weather app on anything else than the GPU: use scalable icons, render them on the GPU. No need to use actual RAM: the GPUs have had their own RAM since times immemorial and GPU rendering is a thing too.
PC games were the last reason why I still used windows. Now that Proton works wonders in Linux, I hope I don’t need to ever come back again. Great times with 98, xp and win7 that were snappy, easy to install and with no slop
i used WKWebView highlightr wrapper around highlight.js for syntax highlighting on iOS, and the webview was the biggest memory line in the app
i mean webKit never handle viewport well when compare to firefox or chrome. it's willing to materialize a 10000*10000 texture when firefox and chrome will think that is too dumb and only load the visible part. It's not a good target if you want to compare windows and mac software quality.
Thanks, React and friends.
"Windows users are fundamentally willing to put up with more bullshit than MacOS or Linux users."
I read this circa 2010 and it stuck with me ever since. Also, have felt this way over the years, when I see Windows users work.
Super interesting; it's been exactly the opposite in my experience. MacOS/iOS users put up with whatever Apple is telling them they should love - Liquid Glass, right? App Store restrictions, right? Lousy AI, right? - whether it's true or not. Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago.
As for Windows, I like living in cities. If you live in a city long enough - at least through a couple of major macroeconomic cycles - you'll see it improve in some ways and some neighborhoods, get worse in some ways and some neighborhoods, then improve again, etc. Cycles. Windows found itself in a downturn the last few years, primarily due to the org structure that took Windows shell away from people who could really look after it, and, yes some of those execs have earned my permanent scorn, like a bad local politician would. Now there's a focused team making that neighborhood better. I'm here for the whole ride.
I'll use Linux on computers I don't have to log into very much, so I don't have that UX problem (case-sensitive command lines? Seriously? The 1970's called...). I'll never move to MacOS City; it's like wanting to live in The Villages. Manicured lawns with no soul.
So I live in Windows Town, it's not perfect, no city is, but it's always changing, always moving, going through ups and downs, and now it has a new "city council" that's making changes for the better. And I'm expert enough to make it great for me, and avoid the "neighborhoods" that suck.
This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:
1. Install uBlock Origin in Edge. 2. Start Edge, browse to MSN Weather. 3. Click the "Add an Application" button in the address bar so I have a Start Menu icon for the page. 4. Delete the in-box Weather app icon.
Now I have the same weather site, no ads, running in about 130MB of RAM.
Enjoy your choice of operating system. Live where you want. Sometimes your city has problems. Move if you want, but don't think you've permanently solved your UX issues if you do, you've just swapped them for different ones.
> to make their installations work just to get a UX that's almost as good as Windows from 20 years ago
To be fair, that was the peak of Windows UI. Also, KDE Plasma is way ahead of Windows (any of them).
1 reply →
> Liquid Glass, right? App Store restrictions, right? Lousy AI, right?
Liquid Glass needs a lot of cleaning up but it’s fine. App Store restrictions mean very little for iOS users in general and next to nothing for Mac users. Lousy AI also means little to nothing on Mac and earns at max a shrug on iOS—you even have a handy little button to disable all Apple Intelligence shenanigans altogether which is something no Windows user can easily do with Copilot.
No, Apple users are most definitely not having to deal with the same level of bullshit Microsoft’s users are. And it’s not even close.
>> Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago
I put in the exact same amount of effort to install a Linux distro on my laptop that I would have to install Windows.
1. Download the ISO 2. Write to a USB drive 3. Reboot 4. Run the installer. 5. ??? 6. Profit
And all for an experience with way less bloat, none of the bundled spyware, more consistent UI design (depending on which desktop you're using), and better perceived performance.
>>This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:
This is still a web app, it doesn't solve the problem of MS being too lazy or cheap to make real desktop apps for things. I mean this is the same company who thought taking the Start Menu of all things and re-making it with web crap was a good idea.
I mean, if the only things you can name are Liquid Glass, App Store and not-so-intelligent AI then it seems like Apple users are actually doing quite well?
It's impossible for every idea to be a hit. Liquid Glass was a miss and they backtracked on some changes and fixed some issues that people were vocal about.
4 replies →
It's called a "monopoly."
As always, Captain Obvious is quick to respond.
The Weather app in Windows is more ads than weather, so it checks out.
What if we make all these apps obsolete with < 1mb options.
100 tools < 100mb.
The complete works of Shakespeare are about 6MiB. I hate that 100MiB is considered efficient for telling me if it's going to rain later.
At some point you just got to be amazed at it and celebrate.
I have 64GB of DDR5 Ram and a 64GB pagefile on a pcie 5 SSD and window 11 still runs like crap.
How much does rainmeter take? I used to load tons of widgets on it in my old laptop. Ahh those were the days
...you know, I keep reading all this stuff about memory prices, and it does suck, but memory is still much cheaper per gigabyte than it was ~15 years ago.
Which matters because the things most consumers are doing on their computers haven't changed in the past 15 years. We browse the web, edit photos, message friends, and so on. AI generally runs on remote servers anyway.
For years, everyone kept saying it was fine that Electron used gigabytes of memory, because on modern PCs memory was plentiful anyway. Well, it's not plentiful anymore! Maybe it's time software developers actually used resources efficiently?
Hey, you even have an LLM to help you now!
But it's literally not cheaper than it was ~15 years ago? Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.
https://www.tomshardware.com/pc-components/ram/scientist-say...
Nobody would like to use DDR3 right now though, you can get cheap DDR3 DDR2 if you want some
>Right now RAM is the same price per GB as it was in 2007 and prices per GB look to continue to rise.
...when looking at nominal prices (ie. not adjusted for inflation). If you adjust for that the furthest back you can go to get that price is 2011. What's more is that because RAM prices are subject to boom and bust cycles, that price has also been reached in 2015. So just by tweaking two parameters we went from 19 years (2007) to 11 years (2015).
1 reply →
We had modern programming toolkits that traded some efficiency for ease of use 20 years ago, along with GPU compositing for maximum smoothness. And that's when Vista came out requiring a whole 1GB to run properly. And other than doubling for 64GB that didn't change through 7, 8, 8.1, 10.
Electron was never a great idea but more and more basic things keep moving to it and the result is a disaster. When you use it for several little things at once it turns from annoying waste into massive waste.
moder engineers.
You are destroying the subtle mechanism of corporate enrichment.
15 years ago 4GB was comfortable and 8GB was abundant.
Today 8GB is bare minimum.
Exactly, isn't that nuts? Especially when we're now paying 15-years-ago prices per gigabyte. What are we getting for that additional space?
But we went from 1080p monitors to 5k monitors and so we are pushing 7x the number of pixels and at roughly twice the bits per pixel.
True, but I don't really think that accounts for the increase in memory usage.
1 reply →
I likely unfairly judge (at a high-level) code security based on how much system resources applications waste. If your app, or OS uses that much resource to perform simple operations then you clearly lack understanding of what the code is doing. How then can I expect it to be secure?
An app which could have been a website.
It is literally the MSN Weather website packaged as a WebView2 app.
I don’t know if this is sarcastic. A lot of bloat in GUI apps is because they are built as websites with a bloated front end, dependencies, custom fonts plus the binary compiled code and the decompressed images cached by the browser.
Is it not?
> Instead, it is essentially an MSN Weather web app built on Microsoft's WebView2 framework. Task Manager shows multiple Chromium-based subprocesses running simultaneously, which contributes to the unusually high RAM usage.
This is what traditions mean!
Anything above 50MB RAM for this is shameful imo and reflect poor engineering.
[dead]
I'm sure the memory pages compress well /s