Windows 11's built-in Weather app wastes more than 1 GB of RAM(notebookcheck.net) |
Windows 11's built-in Weather app wastes more than 1 GB of RAM(notebookcheck.net) |
> 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.
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.
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 be fair, that was the peak of Windows UI. Also, KDE Plasma is way ahead of Windows (any of them).
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.
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.
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.
As always, Captain Obvious is quick to respond.
I've tried using MacOS, and there are so many frustrating things you just have to put up with. Windows is much worse, but to be fair Windows was okay at one point. KDE is, out of the box, seamless, sensible, fast, and unbelievably feature-packed. But even if the default experience isn't your taste, it's trivial to customize it to work however you want. Whatever panels you want, where ever you want, with whatever widgets you want. WYSIWYG with point-and-click. And the windows, too. Window rules, KWin scripts (which are actually full-blown plugins), whatever you want. I want Steam to always open full screen on start up on my second monitor on the third desktop? Sure, I can do that, again point-and-click.
I truly cannot sign the praises of KDE enough. I think everyone who dislikes KDE has probably not delved deep enough. I can recreate the entire GNOME desktop in KDE in an hour. I can recreate MacOS in 30 minutes.
... but that's what you said about Windows:
> Windows found itself in a downturn the last few years
> I live in Windows Town, it's not perfect, no city is
> [...] avoid the "neighborhoods" that suck
Really the original comment just reads like you wanted to rant about Apple users and MacOS and that's it. You didn't really give any strong arguments for why Windows is better than MacOS - and "it's not perfect" is not an argument when in the same post you say the exact same about your preferred OS.
1196 points by ajdude on March 3, 2025 | 1213 comments
That's also bloated, couldn't they find a better comparison to illustrate the egregious waste?
But yeah, I still remember when a weather app would take 10 MB and I was complaining (1999)
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.
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.
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
curl wttr.inhttps://en.wikipedia.org/wiki/Dennis_Fong#/media/File:John_C...
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.
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.
Except when it uses some kind of browser engine to render its UI?
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.
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
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.)
not even being annoying, edge is removing manifest v2 very soon, breaking proper ad blocks just like chrome
UBO Lite (the MV3 version of UBO) seems to work just fine in my experience, at the core function of being an ad blocker,
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.
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.
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.
Really Microsoft? Do you really need all the ads revenue from the weather app?
What’s next? Ads on the start menu?
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.
They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...
Personally I just use my government's website when I need to check the forecast.
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.
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.
- 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.
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.
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.
100 tools < 100mb.
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!
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.)
Sometimes, you need to tell the designers NO. Moving background images don't help people figure out what the weather is going to be.
The rabbit was too hungry to even stop to chew you?
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.
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.
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?
Fine, shutdown the weather and stock ticker apps.
Back in my day 100MB was all you had for all your compute, and somehow programs still ran.
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.
https://web.archive.org/web/20010210023051/http://www.softse...
https://web.archive.org/web/20070210195451/http://www.locutu...
https://www.tomshardware.com/pc-components/ram/scientist-say...
...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).
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.
Today 8GB is bare minimum.
Not your app, it rocks.
Microsoft. It's like some decision-maker thinks it's OK to waste memory as long as it's someone (everyone) elses' memory, but it really adds up if you know anything about scale.
But what they're also doing is a non-businesslike under-utilization of their own resources.
Which is disgraceful in itself on top of that.
They're supposed to have much better AI than average and nobody even bothered to ask ChatGPT why in the world weather should take more than kilobytes?
And if their AI can't do it autonomously in under a megabyte it should be able to give a plausible explanation why not by now, and at least it would be orders of magnitude better than a gigabyte.
I assume yours went smoothly as prompted and it surely is an excellent example :)
This is also why it is very important to have plenty of SWAP space on Windows, even if you have 64 GiB+ of memory. Because applications love to over allocate commit charge.
For more than 15 years in the past, the price in real US$ of DRAM per GB was always higher than today.
During 2014, there was a brief price peak when DDR3 (the standard current then) was slightly more expensive than DDR5 is today.
Still, the fact that now the price per GB is the same as 15 years ago, is bad enough, and it can still become worse.
Feature factory work increases the surface area of every API you touch, and the proliferation of pre-written APIs expands the number of APIs you touch. The combination of the two is not quite O(n²) but the exponent is more than 1, so it's still geometric.
It's bloated not because of a sneaky plan to include revenue generation. It's cheaper to make it bloated because quality is costly. They can externalize costs to users and nobody cares.
There is such a thing as overdesign, but when you’re building a modern application, you must trust your designer’s sense of aesthetics and knowledge of UX patterns—two things engineers are often notoriously bad at.
They "could" make it easy but why bother? I assume next update will make calculator 1 gb download, 2gb ram resident and ADS
My best guess is the GUI is somehow really heavy, wouldn't expect a simple console program that connects to some weather API to require that much RAM. But I never worked on apps like this, so no clear idea.
I also like the weather icons being 4K and having some smooth anmiations.
Not to say that it's gone worse (it has IMHO) but comparing 25 years ago to know doesn't help much. Times were different back then. That's like comparing 1900 travel to today.
Things weren’t actually worse.
Obviously it's not a change that you'd be able to pin a specific human decision-maker (who was marginal on Teams) down as to this change being the difference between a sale or not, but nor is the change in revenue going to be a random number uniformly distributed in (-∞,∞).
If the change was revenue-neutral, the skip level would probably have been justified in seeing if the teams working that project could have found something to do customers actually care about instead.
The window in the article wasn't very big. At most it would have about 10MB of framebuffer, and the images on display would fit into 1MB uncompressed.
We can't excuse typical program waste with screen sizes. Especially when you can switch to 1080p or 720p and watch them still use massive amounts of memory.
Or render everything using css, 100mb is someone not trying. 1gb is absurd abuse that only domestic violence victims put up with.
And to be clear, there's a ton of unnecessary bloat today as well. It's just that even a lean and mean highly hand optimized native app is gonna be way bigger today than it was then, due to compositing, higher resolution assets, higher resolution screens and different design sensibilities. But most apps aren't lean and mean highly hand optimized native apps so.
And I'm saying 98SE already had image-heavy design sensibilities all over.
You don't have to highly hand optimize to run a weather UI in a lean way.
Maybe if you were really rich and only used high end desktops. A lot of the computers I used back then were still 800x600, fancier ones were 1024x768. If you happened to also have a 2D accelerator card you'd potentially have 1280x1024. And lots of apps purposefully ran at a much lower color depth, it was common for games to run at 8 or 16 bit color mode.
And yeah lots of fullscreen-ish things ran in lower color, but this is about desktop mode and I never saw a desktop mode that struggled based on color depth.
nautilus 177 MB
kitty 150 MB
alacritty 107 MB
mpv --idle --force-window 160 MB
winit empty window + OpenGL context 100 MB
tux-manager 69 MB
hexchat 55 MB
gnome-terminal 47 MB
st 12 MB
xterm 12 MB
All these apps are what you would consider native, good apps. Written with Qt, GTK, some in low level langs like C\C++, Rust as well. There is of course different ways to measure the usage and maybe some more testing needs to be done, but stuff like 1-10 MB seems completely unrealistic. I think any empty Qt/GTK app eats 40 MB at least. Only thing that even gets close is st at 12 MB. And mind you it's a terminal (which is 1000x simpler than any modern GUI app, doesn't load any assets etc) and it doesn't even use any GPU accel (which itself seem to add a lot of baseline cost).Honestly I was a bit surprised myself. I have a Rust winit + ash vulkan hardcoded triangle demo app and it eats 86 MB (the binary itself is 5.5 MB). I would love to know, if anyone could explain why GPU accel seems to eat up so much RAM. Like yeah, there are a bunch of images that live on swapchain, but they should all be in VRAM. Outside of that I don't see what would require MBs worth of overhead.
Classic GTK is (much) better (RSS on Linux):
GTK2 14 MB
GTK3 24 MB
Once it was decided that a desktop application must have fancy animation effects (like on smartphones) and be rendered completely on GPU things got very different: GTK4 98 MBBut I agree: using more memory is good, actually, because it means more stuff is being cached. Nautilus is probably pre-indexing directory structure so it doesn't have to read disk every single time you open your home folder. That's good. Oh, and thumbnails. Thumbnails are incredibly expensive memory wise, but very useful!
Also modern apps have A LOT built-in. Tons of font management stuff, accessibility, they work on many different environments. I mean, look at everything that goes into a modern terminal emulator.
But... a weather app is much simpler, IMO, than Nautilus or Kitty.
They clearly spent it on maintaining their independent Chromium instance instead.
Video games are the same (mostly) - everything is rendered in screen space for performance reasons, it's very, very rare, that you would render something into a temporary buffer then composite it on top of the rest of the scene - you would need exceptional reasons for that.
Maybe it's time to get back to the olden days of display servers - where applications would push a list of render commands to the 'display server', which would consist of rendering primitives, which would then take these commands and construct the whole UI on the screen, without the intermediate steps of each app drawing into its own little buffer.
You could always fall back to drawing your own applciations, then asking the display server to composite that, but that would pretty much be the exception, not the norm.
For example, on my 5 years old laptop with integrated AMD GPU, windows 10 calculator in default state uses 33 MB system RAM, 9.6 MB dedicated VRAM. Maximized to FullHD screen, same app uses 36 MB system RAM, 13 MB dedicated VRAM. Maybe the OS counts VRAM as active private working set, maybe the app uses more than 1 buffer.
Regardless of the reason, it’s IMO unrealistic to expect a modern GUI app to consume less memory than required for the frame buffer for its window.
The world doesn't run on personal aesthetics, when nobody is willing to pay for them.
https://en.gamegpu.com/news/zhelezo/defitsit-pamyati-zastavi...
Bwahahah!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
[1] https://play.date/games/cloudburst/
[2] https://raewtf.itch.io/cloudburst
The version at itch.io is free, but the paid version comes with a scoreboard (scroll down a bit in the first link above to see it).
One probably could get this down way below ~1 MiB with a properly tuned straight executable written in C (best not to use any of the "modern" stuff like Rust and Go, their default binary sizes for outputting "Hello, world!\n" are already extreme :-) )
By default anything needs at least 532480 bytes RSS on OSX (I tested it with the most minimal C hello world), so that's a threshold one probably can't beat on OS X at least. We probably could kill that value on Amiga OS with the exact same functionality. :-)
For an extreme example:
curl https://wttr.in/
Inside of a conky widget would do the trick, I think.https://github.com/brndnmtthws/conky/wiki/Lua:-Shell-Integra...