Nicht Benötigtes sollte auch nicht gestartet werden
Die Aussage ist trivial: Programme, die nicht laufen, führen auch zu keinem Stromverbrauch. Anwendungen oder Dienste, die man nicht benötigt, startet man am besten gar nicht. Häufig wird diese Erkenntnis aber nicht berücksichtigt. So wird oft ein Dienstprogramm gestartet, das dann auf Netzverbindungen warten muss, statt zuerst einen Multiplexer auf die notwendigen Verbindungen warten zu lassen und das Programm erst bei Bedarf zu starten. Unter den Betriebssystemen Unix und Linux sorgen die Funktionen "inted" und "xinted" genau dafür.
Bei den Anwendungen haben die Architektur und die Umsetzung einen großen Einfluss auf den Stromverbrauch. Es ist der Ressourcenverbrauch jeglicher Art (CPU, Arbeitsspeicher, Ein-/Ausgabe Operationen), der das System belastet und damit auch den Stromverbrauch verursacht. Eine Festplatte braucht mehr Energie, wenn sich der Schreib-Lese-Kopf bewegt, um die Daten auf der Festplatte zu schreiben oder zu lesen. Am größten ist aber der Einfluss einer Anwendung auf den Stromverbrauch der CPU. Zwei Faktoren spielen hier eine Rolle: Wie viel CPU-Rechen-Power benötigt die Anwendung? Wie häufig weckt die Anwendung unnötigerweise die CPU aus ihrem Stromsparmodus auf?
Die gute Nachricht: Das meiste, was eine Anwendung performanter und effizienter ablaufen lässt, macht sie auch stromsparender. Dabei hat auch die Wiederverwendung von Komponenten einen positiven Einfluss auf den Energiehunger. Die Formel ist einfach: Weniger Rechenzyklen der CPU bedeuten auch einen geringeren Stromverbrauch. Einen Teil der Arbeit erledigt dabei ein optimierender Compiler, dem ein guter und klar strukturierter Code dabei hilft. Noch wichtiger ist die Wahl der richtigen Architektur und der wichtigen Algorithmen.
Leider gibt es Ausnahmen von der schönen Regel: Nicht immer geht eine Leistungsoptimierung Hand in Hand mit dem geringsten Verbrauch von CPU-Zyklen. Die Leistung wird manchmal unter Inkaufnahme von vielen Rechenzyklen erreicht. So rechnen Programme "auf Verdacht" im Hintergrund schon mal Ergebnisse aus, obwohl nicht alle Eingabedaten bekannt sind und gar nicht klar ist, ob die Ergebnisse gebraucht werden. Das verschwendet dann Strom. Oder man parallelisiert ein Programm, damit viele CPU-Kerne benutzt werden. Der Aufwand für die Synchronisierung und die Kommunikation kann aber diesen Vorteil leicht zunichte machen, was sich dann auch in der schlechten Skalierbarkeit des parallelisierten Programms zeigt. Als Daumenregel für das Stromsparen gilt: Nicht mehr Prozesse oder Threads benutzen, als diese noch fast linear skalieren.
Der Einfluss des Hauptspeichers auf den Energiebedarf ist weniger offensichtlich: Speicher-Controller benötigen zwar derzeit eine recht konstante Menge an Strom, unabhängig davon, wie viele Zugriffe stattfinden. Dafür hilft ein großer Speicher aber, Festplattenzugriffe des Betriebssystems zu vermeiden, indem der Inhalt zwischengespeichert (gecachet) wird.
Eine Optimierung, die massiv die Codegröße erhöht - etwa ein hemmungsloses "Inlinen" von Subroutinen oder ein übertriebenes Ausrollen von Schleifen oder das Aufbauen von riesigen Indextabellen - kann den Speicherbedarf so weit erhöhen, dass die minimal bessere Codeeffizienz damit erkauft wird, dass weniger Anwendungen gleichzeitig in den Speicher passen und sich so der Strombedarf doch erhöht.
