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)
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)
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.
That's embarrassing.
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 :)
> It's like some decision-maker thinks it's OK to waste memory as long as it's someone (everyone) elses' memory
My friend, you're giving them way too much credit.
Nobody, especially no decision-maker involved with this, has ever spent a single thought anywhere near any concept related to memory.
It just literally never crossed anyone's mind.
They're supposed to have much better AI than average
I suspect there will be a bit of revelation once people realise how much better AI can make software if prompted correctly. Of course a lot of slop will always exist, but things like https://news.ycombinator.com/item?id=49226923 show that it can be a powerful force multiplier if used right.
[dead]
Not trying to excuse the Windows app's memory usage, but these are vastly different apps. Your app is nice, don't get me wrong, but it doesn't have anywhere near the same number of features as the default weather app. In some ways that's a pro for the Windows weather app (animated radar, easy to pan around in the radar view, extra map modes, lots of graphical elements to the presentation), in some ways yours is better (ad-free, for example).
Don't get me wrong, I imagine one could get close to the same featureset while using <600+ MB of RAM, but an app that just shows a table of numbers and a static PNG for a radar isn't really the same.
FWIW, while your compiled binary is 233kB, when its running its using 2.5-4.5MB.
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.
Apple weather is fully native from what I understand. I suspect the 250MB comes from the video backgrounds they play. Arguably that would be a reasonable thing to sacrifice on low memory systems, you'd barely notice.
I was able to do some tests with AI agent help and got:
- ~45 MB on buffers for animated backgrounds
- ~10 MB used for the Swift language runtime (runtime type information)
- ~44 MB used for system libraries: libSwiftCore, CoreFoundation, libobjc, Metal, VFX
- ~21 MB used on GPU buffers (GPU memory is also part of used system memory because of unified memory)
- ~6.3 MB for the weatherd daemon that actually collects the weather info and makes it available to the weather app and to widgets
- ~6.2 MB used for the display color pipeline (to handle color gamuts proprtly)
- ~7 MB runtime caches (shader compiler cache, libobjc cache, etc.)
- ~1-2 MB used for particle effects
- ~34-40 MB of memory as general heap memory that was otherwise unaccounted for (this seems to mostly be stack memory and threading-related stuff, and the actual application logic)
Overall the app is relatively optimized
Nice find and summary. Of I'm not surprised to see the ~75MB for the high graphical fidelity of the app.
I am however surprised that 10MB is Swift language runtime - with ABI compat this is supposed to be shared, and that the weather daemon is >6MB (surely this is just a simple API client?!).
Relatively optimized? typo?
I think this depends on perspective. Compared to an Electron app, it's significantly better. Compared to a hand-optimised app implemented in a low level language it's not great.
I've not done a lot of Swift/iOS/macOS, but I have a passing familiarity. These numbers are basically what I'd expect for a normal app. In other words I think the relative optimisation comes from the fundamentally better technology choice rather than from being particularly careful about performance.
[dead]
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.
1MB is about the lowest memory usage you can get on Windows 7, because of reasonable tradeoffs made in the operating system to things like buffer and stack sizes. The OS creates a few threads for you, those threads have stacks and they didn't optimize the allocation size of those stacks - they used a currently reasonable default.
Depends on the app/framework but typically phantom threads don’t get started. Also, those stacks aren’t materialized until you write something - they’re all CoW’ed pages from a sentinel 0-filled page the kernel keeps around just for this purpose.
It's been a while, but I believe Windows initialises an internal thread pool & parallelises (some parts of) process start / module loading
You’re right. I hadn’t realized that Windows creates a hidden thread pool under the hood for parallelized DLL loading.
What else might that weather app be doing to justify the memory footprint? MS might suck at memory efficiency, but you can't claim they'd ever miss an opportunity to monetize their users. How can a weather app make MS money? MS has asked themselves this, so maybe we should too.
You're right that it's a matter of incentives, but it's because of cost not revenue.
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.
I play videogames. As soon as it became technically feasible to patch games we began to see videogames come out with first day patches.
When you take away the constraints the slop emerges. You could not make mistakes in software when it was all printed on CDROMs and DVDs.
I remember playing The Elder Scrolls: Daggerfall in the 1990s. It came on CD and was very buggy, and I would periodically call Bethesda and they would send me the newest patches on a floppy disk.
10 MB is ridiculously overbloated. 1 MB or something in that vicinity should be more like it.
I think you guys on HN can be a bit out of touch maybe? On my linux machine (measured with tux-manager):
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.
Yes these are all very, very complex applications though.
But 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.
Counterpoint: Nautilus is both slower and less stable than Windows Explorer on large folders, even though the Linux filesystem is much faster. These super-indexed desktop linux search functions are also dog slow, while `grep` and `find` in the terminal are much faster (for searching inside files), and those certainly don't cache anything.
Windows Explorer crashes for me about ~3 times a day at work, and takes down the taskbar with it, so not sure about more stable. I don't use Nautilus though because it's pretty bare bones compared to Dolphin. Also:
> These super-indexed desktop linux search functions are also dog slow
Baloo-indexed KRunner on Plasma is instant. I index my entire home folder, including hidden files, and I can substring search with imperceptible latency. I can't speak to other search implementations, but yes KRunner + Baloo is much faster than grep.
I'm pretty sure you have a plugin installed for Explorer that makes it crash - while Explorer is far from a perfect piece of software, its not even close to this bad, but it's pretty easy to extend it with COM objects that then run inside the process, that can and do crash the whole thing.
It's a work computer, and from what I see there's no visible plugins. But corporate IT always does some fuck shit (that's a technical term), so I wouldn't be surprised.
I recommend you install
https://learn.microsoft.com/en-us/sysinternals/downloads/pro...
And take a look what DLLs have been loaded into your explorer.exe. Look for non Microsoft-signed ones.
Thunar is very fast compared to Nautilus.
> 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
No it isn't good, and no it probably doesn't because it is kernel's job. I'd rather they don't do double caching, and it's actually worse if they do.
Syscalls are expensive. It's not double caching, it's layers of caching. The kernel caches inside kernel memory space, sure, but you still need a syscall to reach that. Every application has layers of caching, it's very normal. This isn't even the top layer of cache, because of course the CPU itself has multiple caches.
But, for example, in a web application you will commonly cache requests. But then the database also has a cache. And then the filesystem the database is on also has a cache.
> I think any empty Qt/GTK app eats 40 MB at least.
Classic GTK is (much) better (RSS on Linux):
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:GTK used to be considered the bloated option along with QT. My first Linux box had 128MB of ram and it was screaming fast.
At one point I ran graphical linux on a 20 mb ram laptop although admittedly that was very tight.
I also remember running nt4 with photoshop, word, and my IDE (borland delphi) all at the same time and comfortably in 128 mb of ram.
What was the lean option?
These apps have codebases going back to the 2000s when having 256MB ram total was a big deal, yet these apps could contend with that (while offering pretty much identical functionality). I remember one of the big arguments for GTK against Qt was that C++ relied heavily on templates, thus every C++ app would have their own copies of the same functions in RAM, while GTK was C, and a lot of those library pages could be shared. Qt even did some nonstandard tricks to cut down on this duplication, which was unpopular with the C++ people.
My Windows 98 install got ten times faster when I went from 32 MB of RAM to 48 MB of RAM.
A fresh boot of my Windows 98 install at the time, once everything was loaded and settled, used up 27 MB of RAM, meaning that after 5 MB of allocations someone was getting paged out somewhere. That extra 16 MB made a world of difference.
Do bear in mind, though, that we're dealing with a lot more than we were back then. Our hardware is more complex, with more and more complex drivers needed to manage more things. Accessibility is different, screens are larger (my monitor now has 27 times the pixels as my monitor then) meaning more memory required for larger textures which are now composited in hardware rather than re-rendered every frame.
I agree with others that things are ridiculous these days, but it's also easy to see that our expectations also need to adjust somewhat. Still, using a webview for displaying the weather... I get why they do it, but it's a scourge. It's emblematic of their care for the customer, which is nonexistent.
Casey Muratori has complained about the hardware driver overhead, because it is possible for hardware to have standard interfaces without needing a device-specific software translation layer, especially for more basic modes (like framebuffer).
AFAIK, Qt's C++ extensions (moc, meta-object compiler) have nothing to do with how it reduces template bloat from containers, which is by moving some type-independent implementation parts to shared methods.
> mpv --idle --force-window 160 MB
That's still a HUGE amount when you remember mplayer (which mpv was based on) ran on PCs that has had less RAM than that.
Yeah, most of modern Linux wastes memory too. 100MB for a blank OpenGL context? Ridiculous.
10 MB is not too bad for a GUI app. If the app is full screen, display is FullHD and has 8 bit depth, that's almost 8 MB memory for the back buffer alone. Enable HDR and pixels become 8 bytes RGBA16_Float instead of 4 bytes BGRA8_Unorm, twice as much memory.
2 bit 160x144px ought to be enough for anything
Look at Richie Rich over here with his 2 bits!
This is only relevant if we assume CPU rendering. The article described system RAM use, not video RAM use. Task Manager doesn't combine the two.
They clearly spent it on maintaining their independent Chromium instance instead.
True, but many modern computers are using unified memory. On such systems all memory is almost equal, despite often reported differently.
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.
Before Windows Vista, Windows apps normally didn't have framebuffers. There was one framebuffer for the whole screen, and apps drew into it. That's why dragging another window over a non-responsive window left a "slime trail" - the non-responsive window wasn't redrawing parts of itself when the window covering them moved away.
Before Vista, we did not have window previews in task bar and alt+tab. We didn’t have a good multimedia framework based on the hardware codecs: media foundation arriving with Vista wasn’t a coincidence. It was hard to capture and encode desktop for screen recording and presentations: despite MS only added desktop duplication API in Win8, technically Vista and Win7 graphics stacks could already do that, MS just neglected. Also, these aero translucency visuals in Vista and Win7 were nice, until Win8 ruined everything.
All that stuff would be hard to impossible with the older GDI architecture and no desktop compositor process.
> many modern computers are using unified memory.
Not really true. Even machines with integrated graphics in Windows aren't truly using a fully shared memory pool. Usually the hardware reserves a chunk of the system memory for the iGPU.
“aren't truly using a fully shared memory pool” I think with AMD iGPUs I have here (GCN 5.1 and RDNA3 generations) it’s actually unified, at least on Windows 10. The difference between the reserved portion and the rest of the memory is cosmetic.
From Vulkan API POV, the reserved portion has device local and multi instance heap flags, the main heap doesn’t. However, the memory type is identical across all heaps, all of them have device local, host visible and host coherent property flags. And I can confirm VMA library from Vulkan SDK successfully allocates way more device visible memory than the size of that reserved portion.
One thing shared between old software rendered desktops and modern videogames is that they shunned these intermediate 'composited' screens. On the desktop, there used to be the screen, and basically windows used to draw on top of each other, there was no intermediate buffer for the whole window to draw itself to, which would then be smushed together with all others.
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.
There’s a reason why all modern desktop environments are designed the same way: power efficiency when multitasking.
Imagine you have 3 windows visible at the same time: a videogame rendering at the refresh rate of the display 144 Hz, a video player rendering frames at 30 Hz, and a text editor rendering blinking cursor at 2 Hz. Because the videogame wants to deliver frames at 144 Hz, the desktop compositor has to deliver the entire desktop at 144 Hz. Asking the video player and especially the text editor to also deliver frames at that frequency would be wasteful. Irrelevant for desktops with fast discrete GPUs, but directly translates to battery drain on laptops.
I don't think this is any better for power efficiency? You're taking the modern system as an axiom, which it isn't. The old system didn't "deliver frames at" any specific rate. The graphics chipset sent to the monitor whatever was in the framebuffer at a specific rate, and windows updated whenever they wanted to. The text editor didn't "deliver frames at 144Hz" or any other Hz - it updated some of the pixels in the framebuffer when you pressed a key.
It cost nothing to not change the pixels when you didn't press a key, no matter whether you weren't pressing keys at 60Hz or you weren't pressing them at 144Hz.
Most games haven't rendered directly into the "screen buffer" for 15-20 years.
Vast majority of titles use deferred rendering, and lighting is done off screen too. Usually the only thing done to the "screen buffer" is a final post-process pass or a copy.
Deferred renderers work differently from compositors. They still build up the entire displayed frame in screen space, except they dont write into a color buffer like directly, but produce a bunch or intermediate buffers, called G-buffers. Then they have a postprocess pass when they resolve these buffers into the final image.
This is called 'compositing' but its similar in name only. It's a fairly efficient process where each color pixel is produced by reading these buffer targets and producing a final color in a shader.
This is entirely different from what composited apps do, where they build up the app's background into a texture, and push that onto the screen, with potentially multiple screen's worth of windows living in memory. This would be equivalent in video game terms to rendering every character and object in the level as 'stickers' and then making the final image of these cutouts, which would consume tons of RAM uselessly, and would force us to render crazy amounts of detail that would never get shown.
It's one possible rendering pipeline. Is it really most games?
Regardless, video games normally update the entire screen (or window) every frame, because the screen is so dynamic. This is unlike Microsoft Excel which has a mostly static screen. Building Excel as if it's a video game is going to waste resources.
This would really help responsiveness. Keypress to pixel is a huge issue in these bloated frameworks which are running on top of bloated OS
How much money are these companies going to make by reducing their weather app to 1MB, or 10MB? How much is it going to cost them to get there?
The world doesn't run on personal aesthetics, when nobody is willing to pay for them.
These days we have an AI system to do exactly this kind of optimization, too expensive for humans, and too cheap compared to consuming expensive modern hardware
Can AI optimize? All signs point to it writing extensive amounts of unnecessary code
Hey, just a few more years of rising memory prices and it'll actually be a marketing term how much RAM something uses.
The MacBook Neo has only 8GiB of RAM. This is widely decried as not enough. The RAMpocalypse means that 8 GiB is going to have to be enough or else it'll eat into Apple's margins. The Neos are wildly popular though because people have used it and 8 GiB is fine. So while the singular weather app being smaller itself isn't material, in aggregate, macOS being more efficient is something that lets Apple sell a lower spec product while still justifying a higher price and thus better margins for Apple.
Apple has been using the "macOS is more efficient" excuse since the early 2000s to justify skimping on RAM.
Let's not ignore the new "windows copilot laptops" that come with 4GiB.
https://en.gamegpu.com/news/zhelezo/defitsit-pamyati-zastavi...
Insanity. 4GB was often not enough even back in late Windows 7 era.
4GB is completely fine in Windows 7.
Not to mention that on 32-bit without PAE, that was all you could get. Nothing more.
I thought you were limited to 3GB without PAE, since you needed at least 1 GB dedicated to memory-mapped I/O? I was never a PC guy though so I could be mistaken.
> The MacBook Neo has only 8GiB of RAM. This is widely decried as not enough.
Bwahahah!
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
`ansiweather` needs like ~6.28 MiB (measured with `/usr/bin/time -l` on OS X), but it's a bash script that invokes cURL, so there's certainly various overheads there too.
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. :-)
On Linux you can bypass libc and use as little memory as you like. When you don't use libc and don't use dynamic loading there is no strict lower bound although you still start with a certain default stack size.
The KDE Plasma weather app takes in maximum 1MB.
I'm not sure if you're reply hunting or we talk about different apps but how would you fit the Qt runtime, Javascript runtime, font cache, graphics, networking libraries, etc in this limit? This can't physically be under 70 MB, and more like 100-200+ MB.
Sibling comment called it: these are dynamic libs used by the desktop, so the incremental RAM usage is low. That's a good approach! Makes me wonder what the heck MS is doing to get their app to add an incremental gig to memory usage.
DLLs are hopefully shared. But when you run a JavaScript interpreter and load some JavaScript library, in several different processes, that is not shared. Each process gets an independent copy of the library because from the kernel's perspective it's data.
The JavaScript interpreter is shared too since the Plasma Weather app is loaded as a shared library plugin into the Plasma process and uses the functionality already loaded and present in RAM. The same concept is used with background services which run in the kded process. There is no need to have a set of full web browser processes per service.
Correct.
Many of those things are already in memory just from running an empty desktop.
I mean, you're getting dumped on for this, but it seems about right?
For an extreme example:
Inside of a conky widget would do the trick, I think.https://github.com/brndnmtthws/conky/wiki/Lua:-Shell-Integra...
LOL. it's a beautiful!
Unrelated, but it reminds me of this C64 demo [1] I posted earlier this week: the whole thing in 17.8 KB.
[1] https://news.ycombinator.com/item?id=49205592
Even 1MB is too much. I expect a modern weather app to be <20K.
You'll blow past that if you include any graphics at all.