Do AI Models Dream of Faster Code? An Empirical Study on LLM-Proposed Performance Improvements in Real-World Software

1. Il Problema

Nonostante i recenti progressi dei Modelli Linguistici su Grande Scala (LLM) nella generazione di codice, rimane una domanda aperta: gli LLM possono generare codice performante per sistemi software complessi e reali?
La ricerca attuale si concentra prevalentemente su benchmark algoritmici isolati (come HumanEval o LeetCode), che non catturano la complessità dell'ottimizzazione delle prestazioni nel mondo reale (gestione della concorrenza, allocazione della memoria, dipendenze tra file). Inoltre, le valutazioni esistenti spesso mancano di test di prestazioni rigorosi, portando a una sovrastima delle capacità degli LLM. L'obiettivo dello studio è colmare questo divario investigando se gli LLM possano agire come efficaci "Ingegneri delle Prestazioni" in ambienti industriali reali.

2. Metodologia

Gli autori hanno condotto uno studio empirico su larga scala utilizzando un approccio strutturato in quattro fasi:

• Costruzione del Dataset (PerfOpt): È stato creato un dataset di 65 task reali di ottimizzazione delle prestazioni, estratti da quattro progetti Java open-source ad alte prestazioni: Apache Kafka, Netty, Presto e RoaringBitmap. A differenza dei dataset precedenti, questi task sono stati selezionati da commit reali che includevano:

  • Una descrizione del problema di prestazioni.
  • Il codice originale e la soluzione implementata dagli sviluppatori umani.
  • Test unitari per la validità funzionale.
  • Micro-benchmark JMH (Java Microbenchmark Harness) scritti dagli sviluppatori per dimostrare quantitativamente il miglioramento delle prestazioni.
  • Criteri di selezione rigorosi: i task dovevano mostrare un miglioramento statisticamente significativo (test di Wilcoxon signed-rank, $p < 0.05$) e un effetto medio-alto.

• Sperimentazione con gli LLM:

  • Modelli testati: OpenAI o4-mini, Gemini 2.5 Pro, DeepSeek-V3 e DeepSeek-R1 (modelli commerciali e open-weight con capacità di ragionamento).
  • Strategie di Prompting: Sono state testate quattro varianti per valutare l'impatto del contesto:
    1. No Hint: Solo il codice e una richiesta generica.
    2. Prompt con Benchmark: Inclusione del codice JMH.
    3. Prompt con Descrizione del Problema: Inclusione di una descrizione semantica del problema.
    4. Prompt con Entrambi: Codice JMH + Descrizione del problema.
  • Ciclo di Riparazione Automatica: Un sistema iterativo ha corretto i patch che non compilavano o fallivano i test unitari (fino a 3 tentativi).

• Valutazione delle Prestazioni:

  • Esecuzione dei benchmark JMH in un ambiente virtualizzato controllato.
  • Calcolo di un punteggio di prestazione relativo (pss - patch performance score), definito come il rapporto tra le prestazioni del codice patchato e quelle originali (dove $>1.0$ indica un miglioramento).
  • Analisi statistica utilizzando il test di Wilcoxon signed-rank e la dimensione dell'effetto $\hat{A}_{12}$ di Vargha-Delaney.

• Analisi delle Strategie:

  • Classificazione manuale dei patch generati rispetto alla soluzione umana in tre categorie: Match (strategia identica), Alignment (stesso collo di bottiglia, approccio diverso) e Divergence (collo di bottiglia sbagliato).
  • Analisi di complessità del codice (LOC, Cicli di complessità).

3. Risultati Chiave

• Capacità di Ottimizzazione (RQ1):

  • Gli LLM sono in grado di generare patch che migliorano le prestazioni rispetto al codice originale, ma rimangono statisticamente inferiori alle soluzioni degli sviluppatori umani nella maggior parte dei casi.
  • Esiste un'elevata volatilità: in alcuni task specifici, gli LLM hanno scoperto strategie non ovvie superando gli umani, ma in molti altri hanno causato regressioni delle prestazioni (codice più lento).
  • Il contesto è fondamentale: fornire una descrizione esplicita del problema è il fattore principale per ottenere ottimizzazioni significative. Fornire solo il codice o solo i benchmark è spesso insufficiente.
  • I modelli commerciali (es. Gemini 2.5 Pro) tendono a performare meglio di quelli open-weight, ma la differenza si riduce con un prompting ottimale.

• Strategie di Ottimizzazione (RQ2):

  • Complessità Strutturale: I patch generati dagli LLM tendono ad essere più localizzati ma introducono una maggiore complessità ciclomatica rispetto alle soluzioni umane. Gli LLM tendono a ottimizzare attraverso logica elaborata piuttosto che attraverso semplificazioni strutturali.
  • Allineamento vs. Divergenza: Le soluzioni migliori si ottengono quando gli LLM mimano la strategia umana (Strategy Match o Alignment). La Divergence (quando l'LLM ottimizza la parte sbagliata del codice) porta quasi sempre a risultati scarsi o regressivi.
  • Gli LLM faticano a identificare autonomamente i "hotspot" delle prestazioni senza guida semantica.

4. Contributi Principali

1. Dataset PerfOpt: Introduzione di un nuovo benchmark realistico composto da 65 task di ottimizzazione delle prestazioni su progetti Java reali, completi di benchmark JMH, superando i limiti dei benchmark algoritmici isolati.
2. Valutazione Rigorosa: Utilizzo di micro-benchmark JMH e analisi statistica rigorosa per valutare le prestazioni, evitando le trappole delle misurazioni non affidabili comuni negli studi precedenti.
3. Analisi della Volatilità: Dimostrazione empirica che le valutazioni basate su compiti algoritmici forniscono una visione eccessivamente ottimistica delle capacità degli LLM nell'ingegneria del software reale.
4. Identificazione dei Limiti: Evidenziazione del fatto che gli LLM attuali mancano di capacità di profilazione autonoma e di ragionamento diagnostico profondo necessari per l'ottimizzazione delle prestazioni.

5. Significato e Implicazioni

Lo studio conclude che gli LLM attuali non sono ancora pronti per sostituire gli ingegneri delle prestazioni in modo autonomo. Agiscono più come motori di ricerca ad alta varianza che possono talvolta scoprire soluzioni geniali, ma spesso falliscono nel diagnosticare correttamente i colli di bottiglia.

• Ruolo Pratico: Il ruolo più immediato degli LLM è quello di assistente collaborativo. Gli sviluppatori umani devono fornire il contesto diagnostico (dove si trova il problema) e gli LLM possono sintetizzare le implementazioni.
• Futuro della Ricerca: È necessario spostarsi verso sistemi basati su agenti multi-modalità che integrino strumenti di profilazione runtime, tracing e benchmarking dinamico nel ciclo di generazione del codice, piuttosto che limitarsi alla generazione statica di codice.
• Benchmarking: La comunità deve adottare dataset come PerfOpt per valutare realisticamente le capacità non funzionali (prestazioni, efficienza energetica) degli LLM, andando oltre la semplice correttezza funzionale.

In sintesi, mentre gli LLM "sognano" codice più veloce, la realtà mostra che hanno bisogno di una guida esperta per non "sognare a occhi aperti" soluzioni che peggiorano le prestazioni dei sistemi reali.