Ottimizzazione Python, individua i colli di bottiglia prima di intervenire

Il codice rallenta sui dati reali, prima di riscriverlo misuralo e trova il collo di bottiglia¹.

La tentazione è indovinare dove sta il problema. Guardi il sorgente, scegli a intuito il punto “lento”, lo riscrivi. A volte funziona. Spesso no. Rischi di lucidare una parte che non incide. La regola è semplice: misura, poi cambia¹.

Sospetti già un punto critico? Fai una misurazione mirata per confermare o smentire. Ti muovi in una base di codice che non conosci? Usa un profiler, lascia che trovi lui dove il tempo si consuma. In entrambi i casi, intervieni solo sui veri colli di bottiglia, non su ciò che sembra lento a occhio¹.

L’ordine delle mosse conta. Prima sistema algoritmi e strutture dati. Qui si trovano i guadagni maggiori. Solo dopo valuta concorrenza o estensioni in C, e solo se servono davvero. Agire in basso senza aver corretto l’alto di solito spreca tempo e aggiunge complessità¹.

Un esempio pratico: il test di appartenenza. Sulla lista richiede una scansione, costo O(n). Su un set, in media, costa tempo costante. Se fai molti controlli di appartenenza, convertire la lista in un set sposta la pressione via dal ciclo caldo¹.

Ecco uno snippet minimale che mostra il cambio di struttura dati:

# Dati iniziali
items = ["alice", "bob", "carol", "dave", "erin"]
queries = ["erin", "zoe", "bob", "mallory"]

# Versione ingenua: membership su lista (O(n) per controllo)
found_list = [q for q in queries if q in items]

# Versione ottimizzata: costruisci un set una volta, membership media O(1)
item_set = set(items)
found_set = [q for q in queries if q in item_set]

Se devi verificare l’appartenenza molte volte, paga costruire il set all’inizio. Se lo fai una sola volta, la conversione può non convenire. I numeri risolvono il dubbio: misura il caso reale¹.

Le funzioni built-in e la libreria standard spesso spostano il lavoro nel codice C sottostante. Questo riduce il tempo speso nel Python scritto da te. Prima di stringere un ciclo, cerca se esiste già un’operazione pronta che fa quel lavoro. Meno codice da te, meno tempo in interpretato, meno bug¹.

Come organizzare il lavoro in pratica:

• Riproduci il problema con dati realistici. Evita micro-benchmark slegati dall’uso reale¹.
• Misura il punto che sospetti critico. Se non sai dove guardare, profila l’intero programma¹.
• Identifica il collo di bottiglia con i numeri alla mano. Niente intuizioni senza riscontro¹.
• Cambia prima struttura dati e algoritmo. Solo dopo considera soluzioni più invasive¹.
• Rimisura. Tieni le modifiche che spostano davvero l’ago, scarta il resto¹.

Misurazioni mirate e profiling danno una mappa. La correzione giusta segue quella mappa: struttura dati adeguata, passaggi dell’algoritmo chiariti, poi eventuali ottimizzazioni più profonde. Questo approccio lascia una traccia ripetibile: i test di performance diventano parte del ciclo, così ogni nuova modifica si confronta con i costi reali, non con le intenzioni¹.