GreenCode measures the energy a software system actually uses, finds the code and infrastructure hotspots responsible, and optimises them, targeting a saving of more than 15% per project.
Every line of code that runs costs electricity, as a hosting bill and cooling load or as battery drain and heat. GreenCode starts from the scale of the problem: the ICT sector, excluding AI and blockchain, has a carbon footprint comparable to aviation, energy use is the largest contributor to it, and data centres alone already consume around 3% of all energy globally.
As GreenCode's state of the art review puts it, a computer or server can only be as energy efficient as the software allows. The software is the root cause, and it has mostly been treated as a black box. IT departments that buy software rarely have the control or skills to demand efficiency, and end users have no view of it at all.
For a software owner, energy is a cost line nobody is managing; for a CTO, the same workload could run on less infrastructure; for anyone running critical systems on constrained power, such as a hospital on emergency generation, it is a resilience question.
GreenCode treats energy the way a mature engineering team treats quality, security or performance: something to measure, improve and verify rather than estimate. The pipeline has three stages. First, quality baselining: the codebase is indexed and analysed, missing documentation and tests are generated, and quality flaws are refactored out, with Green Software Foundation patterns counted as quality metrics.
Energy optimisation follows. The application is deployed onto a reconstructed version of its own infrastructure, stress-tested and benchmarked. Energy hotspots in code, architecture and infrastructure are identified, and specialised generative AI refactors the areas responsible. The loop repeats until the measured improvement is good enough.
Finally, the optimised code is committed back to the repository on a branch for human review, with a report on what changed and how much energy and cost it saved.
What distinguishes this from a generic performance tune is that energy is recorded before any change, after quality baselining and after each optimisation pass, in the same environment.
Small choices add up. As an illustration, take selection sort, a textbook routine, ordering 15,000 random numbers on a microcontroller wired to an energy meter, and change nothing but how the code refers to the list in memory. In a bench test of exactly this kind, the version using optimised pointer access finished in under half the time, drew about 30% less peak current and used under a third of the energy. The developer who wrote the slower version may never have thought about the choice. Repeated across a chip that ships in millions of products, it becomes technical debt built into hardware, and finding choices like this in real code is an active area of research.
View full sizeGreenCode's headline target is a net energy saving of more than 15% from the start to the end of the GreenCode process for each software product it handles. The consortium chose 15% as the threshold beyond which users see significant commercial value; quality, maintainability and security scores must not regress.
The infrastructure assessment work package is building the measurement side: a benchmarking framework aligned with the GSF Impact Framework, a tool that maps a live IT landscape, a tool that reconstructs a running infrastructure through infrastructure-as-code so that benchmarks run on like-for-like environments, and metering that infers energy expenditure from resource utilisation where direct measurement is not available. The state of the art review compares the available meters, from on-chip counters such as RAPL to container-level tools such as Scaphandre and Kepler, to establish where each can be trusted.
One use case applies GreenCode to banking and insurance mainframe code, where transaction volumes are so high that even small improvements translate into significant CPU and energy savings. Another targets WordPress, which runs around 43% of all websites on a core of roughly 350,000 lines, so that any optimisation found is multiplied across every installation. The direct power draw of optimised software will be measured in an operational data centre, and CPU, RAM and disk demand on database servers is being modelled so that capacity matches need.
For a legacy estate, and 60 to 80% of all software is regarded as legacy, this is the low-hanging fruit: systems never designed with energy in mind that run continuously. New development gets evidence-backed insight into which patterns in the team's own code waste energy.
The saving compounds: software that needs less compute runs on less hardware, generates less heat and extends the useful life of the devices it runs on, reducing replacement cost and electronic waste. It is also cheaper to host, which is usually the argument that gets the work approved.
Energy measurement and infrastructure tooling sits in the infrastructure assessment work package, which delivers the energy monitoring and hotspot toolkit and the infrastructure discovery and reconstruction toolkit. The processing pipeline and benchmarking work package builds the pipeline that runs code QA, infrastructure review, benchmarking and energy optimisation, and certification. The code QA toolkit with green software patterns as quality metrics comes from the static code analysis work package, and the energy-efficient language models that do the refactoring from the green AI work package.
To trial the tools on your own codebase or contribute a use case, get in touch through the contact page.
