Being wary of using too much resources in my own programs I'm always a little surprised and disappointed when I see small utility programs like this use resources like a drunken sailor on shore leave. Flux is currently using 118 MB of real memory and 0.1% CPU.
Using otool -L /Applications/Flux.app/Contents/MacOS/Flux you can see an impressive number of frameworks included. I guess inclusion of the webkit framework is the biggest culprit. Why all this is needed to simply dim the light on my screen is beyond me.
That said, Flux is perfect functionality wise and very useful.
The reason for WebKit is to be able to show a Google Maps frame to help people choose their location to get a more accurate sunrise/sunset. Not sure if that level of accuracy is necessary.
That said, the vast majority of OS X apps will link against the WebKit framework; not just Safari, but also Adium, Tweetbot, Mail.app, Growl, Notes, TextMate, iTunes, etc. It's pretty much guaranteed that it's in memory already, so there's no harm linking against it.
As for memory, ps reports about 64 MB of RSS; Activity Monitor reports 47.5 MB of memory used. Seems okay to me.
I'm using the latest Mountain Lion 10.8.5. On second though, I think I know what is going on.
First, linking with the webkit framework is not the problem, using the framework is. I was playing around with preferences and also location. As you say, this is when the Webkit frameworks kicks in, which might explain the memory blowup to 118MB.
Second, I seem to recall that modern OS allocators are reluctant to release memory back to the OS (pool) unless required (when available memory is low) hence the process appears to use more memory than what it actual might be using. When I just restart Flux without fiddling with preferences, memory usage stays at around 45MB. I still think this is way too high if you think about what the program is doing, but given the above, even if Activity Manager reports that Flux is using 45MB, it might not really use 45MB now, only at some point.
I remember I used Xcode's instruments to investigate my program and could then see that the real active memory used by the process was usually much less than what Activity Manager, top, and ps w/friends were reporting. So a large part of the memory the process is currently holding (45MB) might be released back to the OS if needed, I think. If someone has more details on this, please elaborate.
Edit: Flux is also running with 4 threads(!) which of course also adds to the process memory usage. Isn't a thread stack around 4-8 MB?
Also, Flux appears to use 0.1% CPU continuously which is sloppy since CPU usage can be remedied by putting (nano)sleep in the poll cycle to make it use zero CPU.
It's command-line, like the Linux version, which means it's very lightweight. It's using 0% CPU (looks like 4 seconds of CPU over the last week or two), but it does seem to use 111 MB memory -- I'm curious why and might poke at it. (Yay free software.)
wyvern:~/src/redshift/redshift-1.7/src gthomas$ otool -L redshift
redshift:
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
That's a great idea. I don't use homebrew myself, so that didn't occur to me. I'll try emailing the upstream author first and see if they want it, and submit to homebrew if I don't hear back.
To get redshift to run at login, we'll use launchd. Save the following as ~/Library/LaunchAgents/redshift.plist (modify as needed if your binary and config files are elsewhere).
When we recompiled for 64-bit/universal (from 32-bit before), f.lux's RAM usage went from 6MB to 29MB (but Apple requested that we change it, so we did.) You could probably set f.lux to run in 32-bit mode and have the old footprint.
CoreLocation is an important feature for us, and we have to include a map and a Javascript host to access Google's geolocation service at all. There is no more reliable way than Webkit.
We've considered breaking into a daemon and a GUI, which would also allow us to make a preference pane, but it's a lot of work for not much benefit.
It's using 0.7 mb on my Surface Pro. However, its 6.15pm right now, maybe usage goes up when it actually starts dimming. I've never had noticeable performance issues because of it though, and I run it on my 7 year old Macbook Pro as well.
Using otool -L /Applications/Flux.app/Contents/MacOS/Flux you can see an impressive number of frameworks included. I guess inclusion of the webkit framework is the biggest culprit. Why all this is needed to simply dim the light on my screen is beyond me.
That said, Flux is perfect functionality wise and very useful.