Posted by akyuu 12 hours ago
I made a little conference schedule app a few weeks ago for a conference I was at. I used my own rust UI toolkit, which calls in to cocoa to make use of native UI components. The resulting binary is about 500kb and it uses a couple megs of ram while running. It looks and feels like a totally native iOS app. As far as the OS is concerned, it is.
Even 500kb feels too big for what it is. I’m rewriting the core at the moment, and I think it’ll be more efficient as a result. But I’m still pretty happy with it.
The program that I use to manage my small business, basically a GUI wrapper on an sql DB is a total delight to use, because everything happens instantly. Even opening it is instantaneous.
Modern software is such a bloated mess that you kind of get used to a 20 second start-up and a .25-1 second delay on every action. Then you use something that isn't bloated junk and it feels like actual magic.
I'm curious if you use winit for windowing, or something lower level that's just mac specific.
UI library is here: https://github.com/josephg/leptos-native
And here's the schedule viewer app I made with it. It runs silky smooth on device: https://github.com/josephg/dweb-sched
The whole project is currently experimental & vibe coded. It's missing a lot of components, and it has bugs. I'm currently rewriting it by hand to do it properly.
https://en.wikipedia.org/wiki/Dennis_Fong#/media/File:John_C...
Fortnite, PUBG, COD, all are disgraceful in comparison.
I disagree with Fortnite and PUBG, whilst PUBG is a little clunky it did usher in a completely new game style AND importantly introduced much better situational audio which other games didn't have.
In fact, that seems a lot. Back in ~1996 I was running one of the EFnet servers on a Compaq with 8MB of RAM.
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.
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?
You say tomato we say tomahto
At the end of the day bloated app is a bloated app its consequences are the same.
Fine, shutdown the weather and stock ticker apps.
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.)
What a wonderful world we have created where the fix for a 1GB RAM guzzler reduces it to a mere 130MB.
Now I could start off with my old ZX80 or even my C64 (which is doing fine, thanks, and sports a USB "drive" next to its Quickshot II) but I think my first 80486 is a realistic comparison.
That ran at 25MHz, had a maths co-pro in it had 4MB RAM, a 20MB IDE HDD and I think the Orchid graphics card had 0.5MB RAM. The monitor was of course a 14" CRT VGA. OK so late 1980s!
However, that thing could run Win 3.1 and Word 2 and I think I managed to wedge a dodgy copy of Quark Express on it. I could play F117 and other games on it.
Oh well, lets see what this Linux box has on it:
/usr/bin/inxi - 1.4MB
,_May_1997.jpg){kind=link}
$ inxi -w Yeovil,UK
Weather:
Report: temperature: 16.05 C (61 F) conditions: scattered clouds
Locale: Yeovil, UK current time: Mon 10 Aug 2026 01:16:05 BST
Source: OpenWeatherMap.org
not even being annoying, edge is removing manifest v2 very soon, breaking proper ad blocks just like chrome
Firefox, in contrast, doesn't let the network request fire off to the page until every extension is ready. So chrome is essentially screwing over the user, letting ads/ blocked content load, and intentionally degrading their experience, to make things appear slightly faster.
Yet, I never see ads since ad blockers still have enough power to block ads.
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.
Use Firefox with uBlock Origin, do not use Chrome, Chromium, Edge, Brave, Vivaldi, etc.
> 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.
Wipe Windows from your machine. Use Arch Linux. Problem solved.
Normally though it's ~65 MiB for both clock & weather.
Also mate-screenshot is leaking RAM/processes. About ~40 MiB leaked per screenshot.
These things do tend to get fixed over time, though.
Before you scorn, doing it the opposite way, taking more to use less memory, makes you less promotable, not more.
https://tinkerdifferent.com/threads/snazzy-weather-a-snazzie...
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.
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.
Then C# came and said "we can't use it, we have different needs". So did Go.
It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway:
https://github.com/WebAssembly/gc/issues/77
They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs):
https://github.com/WebAssembly/gc/issues/36
More links:
Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.
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?
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.
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.
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.
No it isn't. It isn't a word process for gods sake. It has one literally one job and 300 MB is like an order of magnitude off for that. This mentalty is the slippery slope that led us to the situation in the OP today.
Not sure what you think "having an SVG renderer in memory" means exactly, typically the way an SVG renderer works is that you give it a huge chunk of memory and ask it to draw pixel data there from the SVG file. So even though the SVG is small on disk, rendering a 1000x1000 image from an SVG is gonna need a 1000x1000x3 byte pixel buffer (assuming no transparency or HDR shenanigans)
Cool, that's 3 MB
Yeah this is irrelevant here, windows doesn't share both in 99 of the case.
It's only been somewhat recent that I've personally seen much hardware that allows for that reservation to be dynamically defined, and not with any Intel integrated graphics so far.
* 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.
* Not every app is fullscreen, but I was using a maximized app as an example. If you make the window smaller then yeah obviously the numbers get smaller proportionally.
* A ton of people have 4k displays, it's difficult to find a moderately high end laptop without a 4k display these days. In any case, that was the hypothetical example I used.
* If you have a window that's roughly 4k resolution, and you want a background picture which fills the entire window, that's gonna be a roughly 4k resolution pixel buffer (unless you stretch a smaller image, but that looks ugly).
* Depends on the text renderer. I have mainly used pangocairo, which is based around CPU rendering text to a pixel buffer. I know that this is the typical recommendation for handling high quality rendering of longer pieces of text with Canvas on the web too. Maybe a typical win32 app actually does render each glyph fresh every frame from a font atlas, I'm not familiar with Windows APIs specifically. I apologise for the inaccuracy if that's the case.
* I'm pretty sure you're wrong here? If DWM has only one buffer which all windows share, how does it handle the case where a partially obscured window goes unresponsive for a bit as the user removes what obscures it? In old school non-composited X11, the answer is that the X server paints in the newly revealed area with grey pixels and asks the window's process to re-render that region, causing a lingering grey region if the app is frozen. Preeeetty sure that Windows 11 doesn't do that. But do you have documentation on this?
The rabbit was too hungry to even stop to chew you?
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.
You'd need better than perfect vision to be able to make use of it, though.
It often wasn't a limitation of your monitor, it was a limitation of your video adapter. Rattling off some common specs of monitors isn't telling the full story of what most random people were actually experiencing.
I still remember having to upgrade our main home desktop at the time of Warcraft I I'd release because it didn't have enough video memory to meet the 8MB minimum needed. That was in 2002 on a machine purchased with XP, a Pentium 4 HT with 512MB of system memory. Not necessarily a low end machine, but obviously not a gaming PC at the time and much newer than many systems sold for Windows 98.
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.
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.
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.
They already exist: https://www.howtogeek.com/windows-11-start-menu-ads-how-to-t...
Avert ye eyes for there are no morals in these bad lands of Redmond!
For operating systems and their bundled applications, Apple's integration is an advantage here; the OS designers work for the hardware company and have aligned incentives. That doesn't mean they necessarily align with their customers, just that they are internally aligned.
Microsoft...do they even care about the snappiness of Windows desktops any more?