I test PGO sui server di database mostrano perché l'ottimizzazione può ridurre la velocità
I test PGO sul database relazionale open source utilizzato da molte applicazioni web, descritti da Percona, mostrano che un'ottimizzazione pensata per rendere più veloce il software del database può anche produrre un eseguibile più lento. In un confronto, una versione compilata con l'ottimizzazione guidata dal profilo (PGO), che utilizza il comportamento registrato del programma per orientare la compilazione, ha offerto un miglioramento inferiore al 5%. Tuttavia, le build personalizzate addestrate con uno specifico test del database sono risultate più lente delle build senza PGO. Si tratta di osservazioni distinte, non della prova che questa tecnica sia sempre vantaggiosa o svantaggiosa.
In un articolo datato 9 ottobre 2026, Percona descrive un'indagine volta a stabilire se abbia senso abilitare PGO per impostazione predefinita sul proprio server di database. Il resoconto è la prima parte di una spiegazione in tre puntate che illustra che cos'è PGO, come funziona, perché una build addestrata con sysbench, uno strumento per i test delle prestazioni, perda prestazioni e come affrontare correttamente l'addestramento. Questa prima puntata riporta il risultato inatteso, ma non ne stabilisce la causa.
PGO modifica il modo in cui viene compilato il software. La compilazione traduce il codice sorgente in un programma eseguibile. Nel processo in due passaggi descritto da Percona, la prima build include la strumentazione, cioè contatori aggiuntivi che registrano l'attività nelle diramazioni, dove l'esecuzione sceglie un percorso; nei cicli, dove le operazioni si ripetono; e nei punti di chiamata, dove una funzione ne invoca un'altra. Su questa build strumentata viene quindi eseguito un carico di lavoro di addestramento rappresentativo, ossia l'insieme delle attività usate per mettere alla prova il programma. I contatori identificano il codice eseguito frequentemente, detto codice caldo, e quello eseguito raramente, detto codice freddo. Una seconda compilazione utilizza queste osservazioni per modellare l'eseguibile risultante.
Il compilatore può utilizzare queste informazioni in diversi modi. Può applicare più intensamente l'inlining alle chiamate frequenti, inserendo le istruzioni di una funzione direttamente dove servono anziché effettuare una chiamata separata. Può disporre i percorsi seguiti più spesso in modo che l'esecuzione prosegua attraverso istruzioni adiacenti, spostando invece in disparte i percorsi usati raramente. Può anche riordinare le funzioni all'interno del file binario, cioè il file eseguibile compilato, in modo che le parti di codice che operano spesso insieme siano vicine. Questo migliora la località nella cache delle istruzioni, consentendo al processore di sfruttare meglio la sua piccola e veloce memoria dedicata alle istruzioni del programma. Anche le chiamate indirette risolte frequentemente, la cui destinazione viene scelta durante l'esecuzione, possono diventare chiamate dirette verso una destinazione nota.
Questi meccanismi spiegano perché la qualità dell'addestramento sia importante. PGO non si limita ad accelerare la sessione di addestramento. Modifica la struttura dell'eseguibile in base all'attività osservata durante quella sessione. La domanda rilevante è quindi se l'addestramento rispecchi il lavoro che il database deve svolgere, non semplicemente se una sessione di addestramento si sia conclusa correttamente. Un profilo fornisce informazioni su uno specifico schema di esecuzione, non una promessa di prestazioni migliori con qualsiasi schema.
Percona riporta due risultati distinti. Il confronto tra una build senza PGO e una versione con PGO ha mostrato un piccolo vantaggio, inferiore al 5%. Separatamente, compilando il database open source con PGO sulla base di una registrazione di sysbench-tpcc, un test delle transazioni del database, la build risultante è stata sistematicamente più lenta di quella senza PGO nei test riportati. Modificare la concorrenza durante l'addestramento, cioè il numero di thread che svolgono lavoro contemporaneamente, non ha ribaltato il risultato: Percona afferma di aver provato un numero di thread compreso tra 128 e 1024. Il resoconto non quantifica il rallentamento nel testo, quindi non vi è una percentuale documentata da associare a questa regressione.
Un'importante precisazione emerge nella discussione tra i lettori. Un commentatore si chiede se tutte le altre impostazioni del compilatore siano rimaste identiche quando PGO è stato disattivato. Il commento suggerisce inoltre di abilitare l'ottimizzazione in fase di linking (LTO), che consente agli strumenti di compilazione di ottimizzare congiuntamente parti di un programma compilate separatamente, e sostiene che possa amplificare i vantaggi di PGO. Si tratta di verifiche proposte da un lettore, non di spiegazioni confermate né di ulteriori risultati sperimentali. Il resoconto fornito non stabilisce se altre impostazioni siano state modificate o se LTO fosse abilitato.
Per chi gestisce database e per le aziende che dipendono dal database open source, la lezione applicabile ad altri contesti è verificare una modifica della build anziché considerare l'etichetta di ottimizzazione una prova di miglioramento. Un confronto utile dovrebbe mantenere costanti le altre impostazioni di compilazione e utilizzare attività che rispecchino l'ambiente d'impiego previsto. Anche l'intervallo di thread riportato mostra perché non si possa presumere che il solo aumento della concorrenza durante l'addestramento risolva una regressione delle prestazioni. Si tratta di un'indagine sulle prestazioni, non della segnalazione di una vulnerabilità di sicurezza.
Per le organizzazioni che si affidano a un supporto operativo esterno, i database gestiti, il monitoraggio e i backup automatici di AEU Data sono pertinenti alla supervisione delle modifiche ai database e alla protezione dei dati archiviati, ma questi servizi non stabiliscono se una determinata build PGO sia più veloce. La questione irrisolta nel primo resoconto di Percona resta specifica: perché questa build addestrata con sysbench abbia perso prestazioni, nonostante un confronto separato tra versioni abbia mostrato un modesto miglioramento.