Una dolce introduzione al Green Coding: scrivere software che respira meglio

Scrivere codice che consuma (e inquina) meno

Visto che sei qui, presumo tu abbia già letto diversi articoli sul green computing e sui suoi benefici ambientali.
Se invece non lo hai fatto, sappi che l’intero settore dell’Information and Communication Technology (ICT) consuma una quantità significativa di energia elettrica e genera una quantità altrettanto significativa di gas serra.
Secondo uno studio del 2024, questo settore rappresentava il 4% del consumo elettrico globale e generava l’1,4% delle emissioni mondiali di gas serra già nel 2020.
Nel frattempo, uno studio del 2018 prevede che, entro il 2040, il volume di gas serra prodotto dall’ICT potrebbe salire fino al 14%.

Il green computing è insieme un movimento, un campo di studio e una pratica, con l’obiettivo di ridurre questi numeri e raggiungere — almeno — la neutralità carbonica nel settore ICT, prima che sia troppo tardi.

Un po’ come gli orchi (sì, proprio loro), il settore ICT è composto da molti strati, ognuno dei quali richiede strategie specifiche per diventare più “verde” (sempre come gli orchi, suppongo).
Il green coding è il green computing applicato allo strato del codice, ovvero: come scrivere codice che consumi meno energia e produca meno gas serra.
Ed è proprio di questo che parla questo articolo.

Linguaggi (più o meno) green

Supponiamo che tu stia iniziando un nuovo progetto di lavoro — o l’ennesimo progetto personale — e che tu abbia la possibilità di scegliere quale linguaggio (o linguaggi) usare.
Ecco: già qui puoi fare green coding, scegliendo un linguaggio più efficiente dal punto di vista energetico.

Nel 2017, e poi di nuovo nel 2020 con uno studio più approfondito, un gruppo di informatici ha confrontato il consumo energetico, il tempo di esecuzione e l’allocazione di memoria — sia di picco che totale — di 27 linguaggi di programmazione tra i più diffusi, su 10 problemi computazionalmente intensivi, ottenendo risultati tanto ovvi quanto illuminanti.

Entrambi gli studi hanno mostrato una correlazione chiara, ma non definitiva, tra consumo energetico e tempo di esecuzione: quasi tutti i linguaggi si sono posizionati in modo simile in entrambe le classifiche.
In altre parole, i linguaggi più veloci tendono anche a consumare meno energia — cosa prevedibile, dato che l’energia spesa è potenza × tempo, e riducendo il tempo si riduce quasi sempre anche l’energia totale.
Il “quasi” deriva dal fatto che la potenza non è costante tra le misurazioni, quindi la correlazione non è perfetta.

Per quanto riguarda la memoria, invece, non esiste quasi alcuna correlazione tra consumo energetico e memoria di picco, mentre esiste una correlazione tra consumo e memoria totale allocata, cioè la quantità cumulativa di memoria usata dal programma in esecuzione.
Sospetto che ciò avvenga perché le operazioni di memoria sono di per sé energivore, ma non ho ancora trovato studi che lo confermino.

Se non hai voglia di leggerti gli studi, ecco la sintesi: i tre linguaggi più efficienti e veloci in entrambi gli studi sono stati C, C++ e Rust, tutti compilati e privi di garbage collector.
Java, pur essendo eseguito su una virtual machine con garbage collector, si è piazzato al quinto posto sia in consumo energetico che in tempo di esecuzione.
Un risultato sorprendentemente alto, e direi rassicurante, considerando che miliardi di dispositivi lo eseguono ogni giorno — come Oracle ci ricordava costantemente.

(Anche se, a dire il vero, pare che ora non lo facciano più. Io non saprei: installo altri JDK, e da terminale Linux.)

JavaScript e TypeScript, invece, si sono piazzati piuttosto in basso: rispettivamente 17° e 19° per consumo energetico, e 16° e 23° per tempo di esecuzione, con coerenza tra i due studi.
Scusate, colleghi front-end.

Detto ciò, sono passati cinque anni dall’ultimo di questi studi, quindi i risultati potrebbero cambiare se ripetuti oggi — anche se non mi aspetto che un linguaggio interpretato superi mai un compilato come C.

Big Green Notation

È importante notare che quegli studi miravano soprattutto a trovare correlazioni statistiche tra tempo di esecuzione e consumo energetico, non a stabilire una relazione causale diretta tra linguaggio scelto e impatto energetico del software.

In altre parole, scegliere il “linguaggio migliore” non è la bacchetta magica del green coding:

1. perché un “migliore” assoluto non esiste,
2. perché ambienti e problemi diversi richiedono linguaggi diversi,
3. e perché per uno stesso problema computazionale, ad esempio ordinare un insieme di dati, esistono decine di algoritmi diversi, con tempi (e quindi consumi) molto differenti.

Fortunatamente, menti più brillanti della mia hanno inventato un modo per classificare gli algoritmi in base a come cresce il loro tempo (e spazio) di esecuzione all’aumentare dell’input:
in altre parole, per capire se aumentando l’input di dieci volte aumenterà di dieci volte anche il tempo d’esecuzione, di meno o (ahimè) di più.

Sto parlando della notazione Big-O.

La Big-O misura come un algoritmo scala con input molto grandi, nel caso peggiore, non quanto sia veloce in generale con input realistici. Per quello servono esperienza, buon senso e benchmarking.

Detto ciò, la Big-O offre un’ottima bussola per scegliere quale soluzione adottare per un problema, e non serve nemmeno saperla calcolare — basta saperla leggere.

Ecco un promemoria essenziale, dal migliore al peggiore:

1. O(1) – Tempo costante, indipendente dalla dimensione dell’input. L’accesso diretto a un array è un esempio.
2. O(log n) – Tempo logaritmico: un aumento esponenziale dell’input causa solo un aumento lineare del tempo. La ricerca binaria è logaritmica.
3. O(n) – Tempo lineare: raddoppiare l’input raddoppia il tempo. La ricerca lineare, nomen omen.
4. O(n log n) – Quasi-lineare: un po’ peggio di O(n), ma il meglio che abbiamo per gli algoritmi di ordinamento. Quicksort è quasi-lineare.
5. O(n^x) – Tempo polinomiale: di solito dovuto a cicli annidati. Se x=2, è “quadratico”.
6. O(xⁿ) – Tempo esponenziale: aumenti lineari dell’input causano aumenti esponenziali del tempo. Il brute-force delle password è esponenziale.
7. O(n!) – Tempo fattoriale: ogni incremento dell’input fa esplodere il tempo in modo… fattoriale. Il problema del commesso viaggiatore risolto a forza bruta ne è un esempio — e un cattivo consiglio.

Ora, probabilmente ti starai chiedendo quando mai dovrai scegliere manualmente un algoritmo di ordinamento invece di chiamare sort() — e avresti ragione.
Nella vita quotidiana di uno sviluppatore, la scelta dell’algoritmo non è quasi mai diretta: spetta a chi sviluppa le librerie o i linguaggi (che, si spera, scelgono quelli migliori).

Ma dove la Big-O torna davvero utile è nella scelta delle strutture dati, perché descrive anche i tempi medi di inserimento, eliminazione e ricerca.
Scegliere la struttura giusta non solo evita bug futuri, ma può ridurre il tempo complessivo di esecuzione e quindi il consumo energetico.

Ad esempio: se il tuo codice esegue raramente inserimenti o cancellazioni ma fa lookup di continuo, meglio scegliere una struttura lenta nei primi due casi ma fulminea nell’ultimo.

Ti piacciono articoli come questo? Ogni mese parliamo di codice che migliora chi lo scrive — performance, buone pratiche, storie vere di sviluppo. 👉 Iscriviti alla newsletter di Sensei per riceverli nella tua inbox.

Green Practices

E dopo?
Scelto il linguaggio e le strutture dati ottimali, arriva il momento di scrivere il codice che lega tutto insieme — e qui le strade si dividono: dal classico “funziona e basta” (ma è un nido di spaghetti ingestibile) al “funziona bene, è leggibile, e non prende fuoco”.

Per fortuna, menti — probabilmente diverse da quella dietro la Big-O, ma non meno geniali — hanno definito le best practice, ossia l’arte di scrivere codice solido, leggibile e mantenibile.
E non sarebbe forse il caso di considerare anche “quanto è green” come un’ulteriore metrica accanto a solidità e manutenibilità?

Se hai risposto sì, non sei solo.
Esistono (almeno) tre repository di best practice sul green coding e il green computing in generale — curiosamente, tutte nate in francese, e solo due tradotte ufficialmente in inglese.
Tra le raccomandazioni: limitare le chiamate HTTP, salvare in locale i dati statici, comprimere ciò che si invia in rete.

Se usi SonarQube, ti interesserà sapere che i plugin Creedengo (ex ecoCode) aggiungono regole basate proprio su queste best practice, mantenute da una community che le aggiorna e le mappa per linguaggio.

Detto ciò, nessuna best practice può sostituire il testing: se vuoi davvero sapere quale parte del tuo codice è la più energivora, devi benchmarkarlo, come faresti per le performance.
Esistono strumenti come Intel RAPL o PowerAPI che misurano il consumo energetico durante i test.

Scheduled at Green’o Clock

Dulcis in fundo: diversi studi hanno dimostrato che l’intensità carbonica dell’elettricità — ovvero quanta CO₂ viene prodotta per generarla — varia molto tra le regioni e, cosa interessante per noi, nel corso del tempo.
Ad esempio, l’energia solare produce di più durante il giorno che di notte: quindi eseguire calcoli pesanti di giorno può ridurre le emissioni rispetto a farlo di notte.

Possiamo sfruttare questo fatto per pianificare i carichi di lavoro più intensivi quando l’intensità carbonica è minima — e sì, esistono SDK e risorse per farlo.
Se poi vuoi spingerti oltre (soprattutto nel caso di applicazioni web), puoi persino distribuire i carichi su data center in regioni diverse, come propone il framework CASPER.

Conclusioni

Il green computing non è una moda, né l’ennesimo buzzword da pitch da conferenza.
È qualcosa a cui, come lavoratori del settore ICT — anzi, come nerd del software — dobbiamo aspirare: un futuro in cui il codice non inquina, non consuma risorse inutilmente, e non contribuisce a soffocarci.

Quindi, la prossima volta che stai per fare un commit, chiediti: è il codice più green che potevi scrivere?

(Un grazie ai curatori del fantastico repository “awesome green software”, da cui ho tratto molte delle risorse citate in questo articolo.)

💬 Vuoi capire come rendere più “green” il tuo stack o i tuoi processi di sviluppo? Parliamone insieme: Sensei aiuta team e aziende a scrivere software più efficiente, sostenibile e di qualità. 👉 Contattaci.