Originariamente inviato da ant_alt
valuta il ciclo per azzerare l'array ogni chiamata della funzione,
... ciclo che di fatto viene eseguito lo stesso con la riga
codice:
    A=B=C=D=E=F=G=H=I=J=K=L=M=N=O=P=Q=R=S=T=U=V=W=X=Y=Z=zero=uno=due=tre=quattro=cinque=sei=sette=otto=nove=dieci=0;
,
anzi, forse addirittura in maniera meno efficiente se le variabili non sono tutte in fila in memoria; con un array la memset potrebbe azzerare il tutto il blocco sfruttando le sue conoscenze su come sia più efficiente indirizzare e scrivere la memoria (su x86 a gruppi di DWORD, se non erro).
il ciclo ulteriore per scorrere e confrontare
... ciclo che il compilatore, se lo ritiene conveniente, può smontare da sé (loop unrolling). Inoltre anche la riduzione delle dimensioni del codice può essere conveniente rispetto al loop unrolling, il poco codice resta tutto in cache e il tempo di accesso ad esso diminuisce.
Si può obiettare che tenendo le variabili separate il compilatore può utilizzare i registri, molto più veloci della cache e della RAM, ma dato che nell'architettura x86 i registri general-purpose sono pochi e qui le variabili sono tante il miglioramento di prestazioni derivante dall'uso dei registri per tre/quattro variabili sarebbe irrisorio.
Ma al di là di tutte queste considerazioni puramente teoriche, tieni sempre presente che "premature optimization is the root of all evil". La cosa migliore è partire da un codice che sia il più pulito e logico possibile, lasciare che l'ottimizzatore del compilatore faccia il lavoro sporco e, se serve la massima efficienza, confrontare le performance della versione pulita e di quella ottimizzata, magari facendosi aiutare da un profiler.