Great work! Let's hope this is an early contribution to a novel way of measuring computational complexity. Power drain, as much as time, is the scarce resource both in data centers and in mobile devices. It's great to think about measuring it.
Wouldn't it be great if our favorite IDEs showed a little yellow lightning bolt indicating suggestions for reducing the power-consumption profile of the code? Some of it could be obvious stuff (StringBuffer in place of string + string in loops, for example). But nonobvious stuff could be flagged too.
Of course, I hope the authors or others will try the same sorts of things on low-power mobile processors, and with workloads closer to the real world.
Where I work the IDE does indeed present this information prominently, if you consider raw cpu usage to be a decent approximation for energy consumption. A function using more than a certain amount of cpu in production is annotated with a little mark and if someone changes it the change review system brings the cost of the code to the attention of the reviewer so they have efficiency in mind when reading proposed changes.
No it is a company-specific hack. The relevant thing would be to have the profile data to begin with. Then you can work that into whatever annotation scheme your IDE offers.
Wish I could upvote this twice. The trend of using electron for desktop apps seems to waste a lot of battery and RAM. Between Atom and Slack I was losing between 3 and 5 GB of RAM. Ended up going back to Sublime and it rarely exceeds 300MB.
Yup, this! I like to have one GUI editor on my machine (I open it once month, because I live in iTerm with tmux and vim) and people on reddit convinced me to give Atom a shot. It has some really neat ideas, but in the end it is such a hog, so I deleted it. I cannot recommend electron as platform to anybody at this right moment. Some elctron apps used more resources and energy than IntelliJ Idea, which is ridiculous considering usage and specter of things that those programs are covering.
I recently had a little feud with the developers of react-native and fresco (the Facebook image loading library) because of their extensive use of Finalizers:
Apart from being unreliable, bad design, it slows GC and instantiation by orders of magnitude, which I considered important, but they did not.
I added a comment about how uninstalling the Facebook app improves the battery life of a phone dramatically, that I deleted afterwards because it was too flamy.
True, but I would have to setup the profiling. Setting up a load generation pattern and a load tool would do the job on a local environment, but this is an obviously involved process that requires looking at the generated profile, response times and such. But, does not tell me an in-lined function is missing the cache a lot and slowing things down?
In broad strokes, what are the most energy costly parts of a computation? One must be particularly bad... I'm guessing CPU activity, because it generates the most heat? If you broke it down further, what's the most expensive parts of it?
What causes divergence between energy efficiency and time complexity? I would expect both roughly scale proportionate to the number of instructions executed.
If we're going for least energy, wouldn't it make sense to compare amongst languages? If it were one of my requirements I would not take Java as a given. I would also not take C++ as a given. I'd measure and choose.
Thanks for posting this. Because of it I just remembered that I saved a slightly similar link [1] and the github repo of the used jvm/scala library [2] into my bookmarks years ago, but haven't read them yet.
This is very useful, but I hope they publish the code to perform this test. Sunacle changes stuff all the time to increase performance, and the numbers will change over time.
Wouldn't it be great if our favorite IDEs showed a little yellow lightning bolt indicating suggestions for reducing the power-consumption profile of the code? Some of it could be obvious stuff (StringBuffer in place of string + string in loops, for example). But nonobvious stuff could be flagged too.
Of course, I hope the authors or others will try the same sorts of things on low-power mobile processors, and with workloads closer to the real world.