Comment by nashashmi
18 hours ago
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)
18 hours ago
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
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.
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.
2 replies →
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.
2 replies →
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.
9 replies →
> 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:
3 replies →
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.
3 replies →
> 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
1 reply →
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.
12 replies →
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
1 reply →
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.
7 replies →
`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.
5 replies →
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.