Does the Language You Choose Change the Carbon Impact of Client UI Apps?
In my previous post here, I went over how you can use the energy monitoring framework built into Windows (on battery powered devices) to estimate the energy consumption of your applications. In this post, I am taking it a step further and using the energy monitoring framework to evaluate application tradeoffs a developer might make to optimize their carbon impact, particularly that of the language and UI framework for the application.
In my previous article I referred to a project that was an attempt to compare the energy use of languages https://github.com/greensoftwarelab/Energy-Languages. In the current case, I chose two languages I was most familiar with, Python and C#, as well as two popular UI frameworks for those languages, Kiva and WPF, and built a basic toy messaging application. I used as close as possible application logic between the two and then measured them for 10 minutes each using the Energy Estimation Engine (E3). Admittedly this is a very basic application and doesn’t have close to the amount of logic a production application would have so I’m more focusing on the delta between the language and frameworks than the overall impact. Code and data for this post is available here: scottcha/MessagingPower (github.com)
Each application is structured as follows:
- Basic UI layout of a text box to show messages sent and received, a message compose text box, a send button, and a test button to trigger a test scenario. I didn’t put any effort to customize the UI.
- I chose to use a local SqlExpress instance server where I write and read messages via a simple ODBC driver.
- The application polls the sever (aka SqlExpress) every 5 seconds to find new messages and appends new messages to the message text box.
- All application framework defaults were used.
- In the test scenario every 6 seconds a new random message between 1 and 255 characters long is sent. Each application was run in full screen and the test machine did not use any power management features, (such as screen dim or sleep).
- Total test scenario was run for 10 minutes.
- Surface Pro 2017
- Windows Prerelease build 20279.1
- Intel i7-7660U (2 cores @ 2.5GHz)
- Ram: 16GB
We can see in the summary that with this type of application the display energy has about 24 times more impact on total energy than the CPU energy. As expected, the display energy is basically identical for each application.
Takeaway 1: The most impactful thing for a UI application is to ensure your application is not incorrectly setting ES_Display_Required which will prevent the system from turning off the screen when your application is running System Sleep Criteria – Win32 apps | Microsoft Docs.
Let’s compare the CPU use for these two applications (the disk usage was very minimal and other factors like network were 0).
According to the results, the Python app varied between 1.38 times more energy at startup to a max of 6.2 times more energy with an average of 2.8 times more energy across the lifetime of the device. This is not nearly as bad as the results in the energy-languages experiment that compared C# and Python at many multiples higher—primarily due to the execution time differences that we do not necessarily have in UI focused applications.
Takeaway 2: The CPU processing energy and carbon produced from Python/Kiva is around 2.8 times that of a C#/WPF application.
Let’s take these values and translate them into carbon numbers to evaluate the potential carbon impact of these choices. Since the display energy is similar between applications, we will remove that from our calculation and focus on CPU energy. Given this is a UI messaging application, let’s assume it’s run for a full 8 hours per day, 5 days a week, for 1 million users in the US.
Using the calculations from the previous article in this series we can estimate the yearly carbon impact:
- C#/WPF is around .00031 mtCO2e per year for that population.
- Python/Kiva is around .00087 mtCO2e per year for that population.
- Difference is .00056 mtCO2e per year.
For this single application, a choice in the language and UI framework is equivalent to about 1.4 miles driven by an average car. The result is not very impactful at the individual application level with the defined carbon and user profile. If the app was more widely distributed or had more resource utilization, there may be a point where language choice could start to make a difference in the carbon impact of the application.
Next Steps for the Project
While we have seen that for a basic UI application the impact may be negligible, it would be interesting to repeat this for both resource applications (such as games or ML training) as well as expand potential language and UI framework choices. If folks are interested in other languages or UI frameworks, please drop a note in the comments or submit a PR to the repo.
In future posts I will tackle quantifying the impacts of getting some of the things noted here wrong, such as preventing the system from entering sleep states, poor algorithm choices or various UI design choices.
Guidance & Call to Action
For UI applications which are not necessarily using resources constantly, the choice of programming language is unlikely to have a large impact on the total CO2 impact from the energy used by that application. For applications with higher resource utilization or broader distribution one might want to do some estimates if language and framework choice is something one is considering.
Check out the Microsoft learn module for a broad overview of the principles of sustainable software engineering: The Principles of Sustainable Software Engineering – Learn | Microsoft Docs