- ~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)
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?!).
Oh yea, something worth mentioning is that my analysis did not consider what memory was shared or not. That might influence the actual numbers. I believe the amount of memory used by the weatherd daemon also includes code and not just the heap memory, so the libraries that weatherd loads would be included in that.
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.
Yea this is what I meant. I guess a more accurate phrasing would be "feels reasonably optimized." Qualitatively in terms of (lack of) graphical stutters and whatnot the macOS one feels very smooth.
- ~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