In der modernen Welt läuft Software auf allem, von den Telefonen in unseren Taschen bis hin zu den massiven Rechenzentren, die das Internet antreiben. Während wir den Energieverbrauch oft als ein Hardware-Problem betrachten – also der Frage, wie viel Strom ein Server oder eine Batterie verbraucht –, spielt die Software selbst eine massive Rolle. Genau wie zwei verschiedene Routen zum selben Ziel unterschiedlich viel Zeit und Treibstoff benötigen können, können zwei verschiedene Code-Stücke, die exakt dieselbe Aufgabe erledigen, sehr unterschiedliche Mengen an Energie ziehen. Wenn diese Software Millionen Mal am Tag ausgeführt wird, summieren sich diese kleinen Unterschiede zu erheblichen Kosten und Kohlenstoffemissionen. Die Herausforderung für Entwickler bestand bisher darin, dass diese Energiekosten unsichtbar sind. Wenn ein Programmierer Code schreibt, erhält er sofortiges Feedback darüber, ob er korrekt funktioniert oder wie schnell er läuft, aber er erhält kein Signal, das ihm mitteilt, ob seine Änderung die Software energieeffizienter oder weniger effizient gemacht hat. Diese Lücke führt dazu, dass ineffizienter Code oft unbemerkt in die Produktion gelangt, wo er weiterhin unbemerkt Energie verschwendet.

Ein Team von Forschern an der Lappeenranta-Lahti University of Technology in Finnland setzte sich zum Ziel, diese unsichtbare Energie innerhalb der Werkzeuge, die Entwickler jeden Tag nutzen, sichtbar zu machen. Sie testeten ein System, das als Rückkopplungsschleife fungieren soll und drei verschiedene Schritte miteinander verbindet: eine Änderung am Code vorzunehmen, die Energie dieser Änderung automatisch zu messen und jede Erhöhung des Energieverbrauchs als Fehler zu markieren, ganz ähnlich wie ein Test, der nach Fehlern (Bugs) sucht. Um zu sehen, ob dies in der realen Welt funktioniert, wandten sie ihr System auf zwei Open-Source-Softwareanwendungen und eine standardisierte automatisierte Test-Pipeline an. Sie schlugen nicht nur eine neue Idee vor; sie bauten sie, ließen sie laufen und maßen die Ergebnisse. Ihre Arbeit zeigt, dass es möglich ist, Energieverschwendung in dem Moment zu erfassen, in dem ein Entwickler eine Änderung einreicht, indem zwischen einem echten Problem im Code und den normalen, harmlosen Schwankungen unterschieden wird, die auftreten, wenn Computer auf gemeinsam genutzter Infrastruktur laufen.

Die Forscher begannen damit zu testen, ob spezifische Änderungen am Code tatsächlich gemessen werden konnten, um einen Unterschied im Energieverbrauch aufzuzeigen. Sie wählten zwei bekannte Softwareanwendungen aus und führten gezielte Änderungen an jeder vor. In der ersten Anwendung entfernten sie einen redundanten Schritt, bei dem die Software dieselbe Information zweimal in einer Datenbank abfragte. In der zweiten Anwendung organisierten sie die Art und Weise neu, wie die Software Artikel abruft, indem sie wiederholte Schritte in einem einzigen, saubereren Prozess zusammenfassten. Sie ließen die Test-Suite der Software dann zwanzig Mal für jede Version – zehn Mal mit dem ursprünglichen Code und zehn Mal mit dem neuen Code – auf einer dedizierten Maschine laufen, um einen fairen Vergleich zu gewährleisten. Die Ergebnisse waren eindeutig. Die erste Anwendung zeigte eine Reduktion des Gesamtenergieverbrauchs um etwa acht Prozent, während die zweite eine Reduktion von über einundzwanzig Prozent aufwies. Entscheidend war, dass die Forscher feststellten, dass diese Einsparungen primlich dadurch zustande kamen, dass die Software ihre Aufgaben schneller erledigte, anstatt dass sie in einem einzelnen Moment weniger Strom verbrauchte. Diese Unterscheidung ist wichtig: Der Code war einfach effizienter darin, die Aufgabe schnell zu erledigen, was den gesamten Energieverbrauch natürlich senkte.

Nachdem sie bewiesen hatten, dass Code-Änderungen messbar sind, gingen die Forscher zur nächsten Herausforderung über: die Integration dieser Messung in einen Live-Workflow. Sie bauten eine Pipeline, die jedes Mal läuft, wenn ein Entwickler neuen Code einreicht, ein Prozess, der als Continuous Integration bekannt ist. Dieses System maß die Energie auf zwei Ebenen. Erstens betrachtete es die gesamte Test-Suite als Ganzes. Zweitens maß es die Energie einzelner Anfragen, wie etwa einer einzelnen Suche oder eines einzelnen Datenabrufs, um genau zu sehen, wo Energie verbraucht wurde. Sie fanden heraus, dass die Energiewerte auf den gemeinsam genutzten Computern, die für diese Tests verwendet wurden, überraschend stabil waren. Die natürliche Variation zwischen den Durchläufen war gering genug, dass das System zuverlässig zwischen normalem Rauschen und einem echten Problem unterscheiden konnte. Diese Stabilität ermöglichte es dem System, eine Baseline, also einen Standard für die normale Leistung, festzulegen, an dem jede neue Code-Sequenz gemessen werden konnte.

Der letzte Test bestand darin zu sehen, ob das System einen Fehler erkennen kann. Die Forscher schleusten absichtlich zwei Arten von energieverschwendenden Fehlern in den Code ein, um zu sehen, ob die Pipeline sie melden würde. In einem Szenario änderten sie den Code so, dass er die Datenbank um Informationen einzeln statt alle auf einmal fragte – ein häufiger Fehler, der massive Ineffizienz verursacht. Im anderen Szenario fügten sie eine rechenintensive Aufgabe zu nur wenigen spezifischen Teilen der Software hinzu. Das System funktionierte genau wie erhofft. Wenn der Fehler das gesamte System betraf, markierte die Pipeline den gesamten Build als fehlerhaft. Wenn der Fehler lokal auf nur wenige spezifische Funktionen begrenzt war, identifizierte das System korrekt diese spezifischen Funktionen als das Problem, während der Rest der Software durchging. Diese Fähigkeit, den genauen Ort der Verschwendung zu lokalisieren, macht den Ansatz für Entwickler praktikabel, da er ihnen genau sagt, was sie korrigieren müssen.

Die Studie hob auch die praktischen Realitäten der Nutzung eines solchen Systems hervor. Da die Computer, auf denen diese Tests laufen, gemeinsam genutzte Ressourcen sind, die sich im Laufe der Zeit ändern können, musste das System eine Möglichkeit besitzen, seine Standards anzupassen. Die Forscher fanden heraus, dass die Energiewerte drastisch schwanken würden, wenn sich die zugrunde liegende Hardware ändert, was potenziell zu Fehlalarmen führen könnte. Um dies zu lösen, enthält ihr System einen Mechanismus, der seine Baseline automatisch neu kalibriert, wann immer der Code erfolgreich zusammengeführt (merged) wird, wodurch sichergestellt wird, dass die Standards immer die aktuelle Umgebung widerspiegeln. Dies verhindert, dass das System guten Code blockiert, nur weil sich der Computer, auf dem er läuft, geändert hat. Die Forscher merkten an, dass das System zwar in ihren kontrollierten Tests gut funktionierte, die spezifischen Zahlen, die sie fanden – wie die acht- oder einundzwanzigprozentigen Reduktionen – jedoch von den spezifischen Anwendungen und der Art der Code-Änderungen abhängen. Sie behaupteten nicht, dass jede Code-Änderung um diesen Betrag Energie sparen würde, sondern dass die Methode, diese Änderungen zu messen und zu melden, praktikabel ist.

Letztendlich liefert diese Forschung einen Beweis dafür, dass Energieeffizienz wie eine routinemäßige Qualitätsprüfung behandelt werden kann, genau wie die Prüfung auf Bugs oder die Geschwindigkeit der Performance. Indem sie den Energieverbrauch innerhalb des Entwicklungs-Workflows sichtbar und handhabbar macht, befähigt das System Entwickler, informierte Entscheidungen zu treffen, bevor ihr Code veröffentlicht wird. Die Studie bestätigt, dass die drei technischen Komponenten – das Messen des Codes, die Integration der Daten in die Pipeline und die Erkennung von Regressionen – zusammen als eine einzige Schleife funktionieren können. Während die Forscher einräumen, dass eine breitere Anwendung eine weitere Evaluierung dessen erfordert, wie Entwickler auf diese Signale reagieren, ist die Kernbotschaft solide: Es ist möglich, ein System zu bauen, das Energieverschwendung in Echtzeit erfasst und so ein unsichtbares Problem in einen handhabbaren Teil des Softwareerstellungsprozesses verwandelt.