Nel mondo moderno, il software gira su tutto, dai telefoni nelle nostre tasche ai massicci data center che alimentano internet. Sebbene spesso pensiamo al consumo energetico come un problema di hardware — ovvero di quanta elettricità consumi un server o una batteria — il software stesso gioca un ruolo fondamentale. Proprio come due percorsi diversi per raggiungere la stessa destinazione possono richiedere tempi e carburante differenti, due diversi pezzi di codice che svolgono esattamente lo stesso compito possono assorbire quantità di energia molto diverse. Quando questo software viene eseguito milioni di volte al giorno, queste piccole differenze si sommano in costi e emissioni di carbonio significativi. La sfida per gli sviluppatori è stata a lungo il fatto che questo costo energetico sia invisibile. Quando un programmatore scrive del codice, riceve un feedback immediato sul fatto che funzioni correttamente o sulla sua velocità di esecuzione, ma non riceve alcun segnale che gli indichi se la sua modifica abbia reso il software più o meno efficiente dal punto di vista energetico. Questa lacuna significa che il codice inefficiente spesso scivola in produzione, dove continua a sprecare energia inosservato.

Un team di ricercatori presso l'Università di Tecnologia Lappeenranta-Lahti in Finlandia si è posto l'obiettivo di rendere visibile questa energia invisibile all'interno degli stessi strumenti che gli sviluppatori usano ogni giorno. Hanno testato un sistema progettato per agire come un ciclo di feedback, collegando tre fasi distinte: apportare una modifica al codice, misurare automaticamente l'energia di quella modifica e segnalare qualsiasi aumento dell'uso di energia come un fallimento, proprio come un test che controlla la presenza di bug. Per vedere se questo funzionasse nel mondo reale, hanno applicato il loro sistema a due applicazioni software open-source e a una pipeline di test automatizzata standard. Non si sono limitati a proporre una nuova idea; l'hanno costruita, l'hanno eseguita e ne hanno misurato i risultati. Il loro lavoro dimostra che è possibile intercettare lo spreco energetico nel momento stesso in cui uno sviluppatore invia una modifica, distinguendo tra un problema reale nel codice e le normali, innocue fluttuazioni che si verificano quando i computer operano su infrastrutture condivise.

I ricercatori hanno iniziato testando se specifiche modifiche al codice potessero effettivamente essere misurate per mostrare una differenza nell'uso dell'energia. Hanno selezionato due applicazioni software ben note e hanno introdotto modifiche mirate a ciascuna di esse. Nella prima applicazione, hanno rimosso un passaggio ridondante in cui il software cercava due volte la stessa informazione in un database. Nella seconda, hanno riorganizzato il modo in cui il software recuperava gli articoli, consolidando i passaggi ripetuti in un unico processo più pulito. Hanno poi eseguito la suite di test del software venti volte per ogni versione — dieci volte con il codice originale e dieci volte con il nuovo codice — su una macchina dedicata per garantire un confronto equo. I risultati sono stati chiari. La prima applicazione ha mostrato una riduzione del consumo energetico totale di circa l'otto per cento, mentre la seconda ha mostrato una riduzione di oltre il ventuno per cento. Fondamentalmente, i ricercatori hanno scoperto che questi risparmi derivavano principalmente dal fatto che il software completava i suoi compiti più velocemente, piuttosto che perché assorbiva meno potenza in un singolo istante. Questa distinzione è vitale: il codice era semplicemente più efficiente nel portare a termine il lavoro rapidamente, il che naturalmente riduceva l'energia totale consumata.

Dopo aver dimostrato che le modifiche al codice potevano essere misurate, il team è passato alla sfida successiva: integrare questa misurazione in un flusso di lavoro live e automatizzato. Hanno costruito una pipeline che viene eseguita ogni volta che uno sviluppatore invia nuovo codice, un processo noto come integrazione continua. Questo sistema misurava l'energia a due livelli. In primo luogo, analizzava l'intera suite di test nel suo complesso. In secondo luogo, misurava l'energia di singole richieste, come una singola ricerca o un singolo recupero dati, per vedere esattamente dove veniva utilizzata l'energia. Hanno scoperto che sui computer condivisi utilizzati per questi test, le letture energetiche erano sorprendentemente stabili. La variazione naturale tra le esecuzioni era abbastanza piccola da permettere al sistema di distinguere in modo affidabile tra il rumore normale e un problema reale. Questa stabilità ha permesso al sistema di impostare una base, o uno standard di prestazione normale, rispetto al quale ogni nuovo pezzo di codice poteva essere confrontato.

Il test finale consisteva nel vedere se il sistema fosse in grado di intercettare un errore. I ricercatori hanno deliberatamente iniettato due tipi di errori che causano sprechi energetici nel codice per vedere se la pipeline li avrebbe segnalati. In uno scenario, hanno modificato il codice in modo che chiedesse le informazioni al database una alla volta invece che tutte insieme, un errore comune che causa un'inefficienza massiccia. Nell'altro, hanno aggiunto un compito computazionale pesante a solo alcune parti specifiche del software. Il sistema ha funzionato esattamente come sperato. Quando l'errore ha influenzato l'intero sistema, la pipeline ha segnalato l'intera build come un fallimento. Quando l'errore era localizzato solo in alcune specifiche funzionalità, il sistema ha identificato correttamente quelle specifiche funzionalità come il problema, lasciando che il resto del software passasse il test. Questa capacità di individuare l'esatta posizione dello spreco è ciò che rende l'approccio pratico per gli sviluppatori, poiché dice loro esattamente cosa correggere.

Lo studio ha anche evidenziato le realtà pratiche dell'utilizzo di un tale sistema. Poiché i computer che eseguono questi test sono risorse condivise che possono cambiare nel tempo, il sistema aveva bisogno di un modo per regolare i propri standard. I ricercatori hanno scoperto che se l'hardware del computer sottostante cambiava, le letture energetiche si sarebbero spostate drasticamente, causando potenzialmente falsi allarmi. Per risolvere questo problema, il loro sistema include un meccanismo per ricalibrare automaticamente la propria base ogni volta che il codice viene integrato con successo, assicurando che gli standard riflettano sempre l'ambiente corrente. Ciò evita che il sistema blocchi del buon codice solo perché il computer su cui viene eseguito è cambiato. I ricercatori hanno osservato che, sebbene il sistema funzionasse bene nei loro test controllati, i numeri specifici che hanno trovato — come le riduzioni dell'otto o del ventuno per cento — dipendono dalle specifiche applicazioni e dal tipo di modifiche al codice apportate. Non hanno sostenuto che ogni modifica al codice risparmierebbe tanta energia, quanto piuttosto che il metodo per misurare e segnalare tali cambiamenti è percorribile.

In definitiva, questa ricerca fornisce una prova di concetto del fatto che l'efficienza energetica può essere trattata come un controllo di qualità di routine, proprio come il controllo di bug o della velocità di esecuzione. Rendendo il consumo energetico visibile e azionabile all'interno del flusso di sviluppo, il sistema permette agli sviluppatori di prendere decisioni informate prima che il loro codice venga rilasciato. Lo studio conferma che i tre componenti tecnici — misurare il codice, integrare i dati nella pipeline e rilevare le regressioni — possono lavorare insieme come un unico ciclo. Sebbene i ricercatori riconoscano che un'adozione più ampia richiederà ulteriori valutazioni su come gli sviluppatori reagiranno a questi segnali, la scoperta fondamentale è solida: è possibile costruire un sistema che intercetti lo spreco energetico in tempo reale, trasformando un problema invisibile in una parte gestibile del processo di creazione del software.