Il software è lento per design, non per il linguaggio

C può essere cinquanta volte più veloce di Python. Eppure riscrivere un programma in C raramente lo rende cinquanta volte più rapido. Nella maggior parte dei casi, il tempo lo consuma l’I/O. Qui la scelta del linguaggio conta poco¹.

Molti sostengono che l’IA renderà il software più veloce riscrivendolo in linguaggi più rapidi, come C o Rust. L’idea: traduci un programma da un linguaggio “lento” a uno “veloce”, ottieni un grande guadagno. Nella generalità dei casi non succede. La velocità del linguaggio non tocca il collo di bottiglia principale¹.

Che esistano differenze notevoli tra linguaggi è vero: C può essere molto più rapido di Python. Ma non segue che riscrivere un programma in C lo acceleri dello stesso fattore. Le prestazioni reali dipendono da dove il programma spende il tempo. Di solito lo spende in I/O, non nell’esecuzione delle istruzioni del linguaggio¹.

Un esempio: un sito CRUD con un database. Per una singola richiesta, circa il 50% del tempo può andare in query per prendere l’utente corrente, il record richiesto, eventuali appartenenze o impostazioni. Se riscrivi il sito in C, puoi accelerare solo l’altro 50%. C’è un tetto duro ai miglioramenti. Nel migliore dei casi raddoppi la velocità della richiesta, in pratica più vicino a 1,5 volte che a 2¹. Non è un risultato trascurabile, ma non è l’ordine di grandezza che il confronto tra linguaggi potrebbe far pensare.

Dove invece la velocità del linguaggio conta, molti linguaggi “lenti” hanno librerie popolari che sbloccano prestazioni simili a C. Non serve riscrivere tutto per ottenere velocità nelle parti critiche: si possono usare queste librerie per il lavoro pesante e mantenere il resto del codice com’è¹.

Il punto di fondo è il design. Le prestazioni sono una questione di progetto più che di linguaggio. Se l’architettura costringe a spendere gran parte del tempo in I/O, il programma resterà lento anche dopo una traduzione in un linguaggio più efficiente. Al contrario, un buon disegno può spostare l’ago, riducendo il peso dell’I/O e aprendo margini di miglioramento che il semplice cambio di linguaggio non dà¹.

Per questo, l’aspettativa che l’IA “riscriva e risolva” non regge. Non perché i linguaggi più rapidi non offrano vantaggi, ma perché spesso non governano la parte di tempo che determina la prestazione complessiva. Se metà della richiesta vive nel database, accelerare la sola metà rimanente non produce un salto di un ordine di grandezza. Produce, al meglio, un miglioramento moderato, spesso più vicino a 1,5 volte che a 2¹.

Questo ridimensiona le promesse di accelerazioni basate soltanto sul cambio di linguaggio: dove conta davvero, la leva è nel progetto e in come si gestisce l’I/O, non nel dialetto che esegue il codice¹.