Install base, not percentage, is the number that matters.
Teams pick optimisation targets by what annoys them, not by where the energy is. A small saving in software running on millions of machines beats a big saving in a tool run once a month.
GreenCode's climate case shows that a saving counts again on every machine that runs the code.
GreenCode helps tackle this by weighing each system by its install base, not just its size, so a saving is counted on every copy. Its reports show where capacity can be retired, so the saving is banked rather than spent. More on this.
Install base, not percentage, is the number that matters. Teams often pick what to optimise by what annoys them. Not by where the energy goes. A small saving on millions of machines beats a big saving on one. Especially if that one tool runs once a month. An optimised release cuts energy from the day it deploys, on every copy. Here is the fix you can use today. List your systems by how many copies are deployed, and hours run. Tools like cloc give a quick size for each codebase. Then score carbon per unit of work, using the Software Carbon Intensity method. Put code that runs everywhere, all the time, first. Send fixes back to the open-source projects you depend on. Then every install gains. GreenCode's climate case shows a saving counts again on every machine running the code. GreenCode helps tackle this by weighing each system's install base, not just its code. Its reports show where capacity can be retired, so the saving is banked. That was GreenCode Tech Tip number forty-one. Follow for the next tip, and find more on greencode.ai/tech-tips.
Share this