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.
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.
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 :)
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.
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.
- ~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
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?!).
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.
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.
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.
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.
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
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.
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.
> 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.
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.
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.
Classic GTK is (much) better (RSS on Linux):
GTK2 14 MB
GTK3 24 MB
GTK4 98 MBI also remember running nt4 with photoshop, word, and my IDE (borland delphi) all at the same time and comfortably in 128 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.
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.
They clearly spent it on maintaining their independent Chromium instance instead.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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/
https://github.com/brndnmtthws/conky/wiki/Lua:-Shell-Integra...
Edit: I see the "250MB" line later in the article. This article is itself bloated for repeating nearly the same thing again.
It is using 122.7 MB at present.
curl wttr.in