Ivan Centamori

EN IT

Gli array in PHP

Nei miei progetti e su questo blog esploro spesso come portare PHP oltre i suoi confini tradizionali. Che si tratti di scrivere da zero un motore di ricerca vettoriale basato su HNSW o di ripensare il design degli ORM, c'è un tema ricorrente: quando inizi a manipolare quantità massicce di dati, la comodità si scontra con le performance. E in PHP, nulla è più comodo — e potenzialmente insidioso — dei nostri amati array.

Gli array di PHP sono, a conti fatti, un capolavoro di ingegneria flessibile. Non sono semplici vettori; sono mappe ordinate, implementate internamente come Hash Table. Puoi usarli come liste, stack, code, dizionari e alberi. Ma questa onnipotenza ha un prezzo computazionale. Ogni volta che aggiungi un elemento, PHP deve calcolare hash, gestire collisioni e mantenere l'ordine di inserimento tramite una complessa struttura di puntatori.

Quando gestisci dieci, cento o mille elementi, non te ne accorgi. Ma cosa succede quando devi caricare in RAM un milione di embedding vettoriali o matrici di grandi dimensioni per il calcolo scientifico? Il tuo server inizia a sudare e la memoria si esaurisce rapidamente.

È qui che entra in gioco un gioiello spesso dimenticato della Standard PHP Library (SPL): SplFixedArray.

La genesi di SplFixedArray

Per capire il valore di SplFixedArray, dobbiamo tornare all'epoca di PHP 5.3, quando la SPL ha iniziato a diventare una componente fondamentale del linguaggio. In quegli anni, le Hash Table di PHP erano enormemente inefficienti dal punto di vista della memoria. Ogni singolo elemento dell'array richiedeva la creazione di svariati zval (le strutture C che definiscono le variabili in PHP) e puntatori sparsi ovunque nella RAM. Questo causava non solo un consumo di memoria spropositato, ma anche una frammentazione eccessiva che distruggeva la cache della CPU.

La risposta degli sviluppatori core è stata SplFixedArray. L'obiettivo era fornire agli sviluppatori PHP una vera e propria struttura dati "in stile C": un array a dimensione fissa, allocato in un blocco di memoria contiguo, indicizzato esclusivamente da numeri interi sequenziali.

Nessuna funzione di hashing, nessun mantenimento dell'ordine di inserimento tramite linked lists. Solo un indice puro e un valore. All'epoca, passare da un array nativo a uno SplFixedArray per grandi iterazioni di dati significava tagliare il consumo di memoria del 50-60% e raddoppiare la velocità di esecuzione.

L'impatto di PHP 7

Se state leggendo questo articolo oggi, probabilmente lavorate con PHP 8.x (magari con il JIT attivato, come consiglio sempre nei miei esperimenti). E qui le cose si fanno interessanti.

Con l'avvento di PHP 7, lo Zend Engine ha subito una riscrittura colossale. La struttura interna degli array (zend_array) è stata rivoluzionata: i bucket ora vengono allocati in un blocco di memoria contiguo e gli array composti solo da indici numerici continui (i cosiddetti "packed arrays") sono stati enormemente ottimizzati, ignorando la logica di hashing quando non serve.

Molti sviluppatori hanno subito gridato alla morte di SplFixedArray. "Gli array nativi ora sono velocissimi, la SPL non serve più!", si leggeva nei forum.

Ma la realtà ingegneristica è più sfumata. Anche se il gap prestazionale si è drasticamente ridotto (e in alcuni casi di micro-ottimizzazione, l'accesso a un array nativo può essere più veloce a causa della mancanza di overhead derivante dalla chiamata di un oggetto), SplFixedArray mantiene dei vantaggi unici. Non deve preoccuparsi della capacità dinamica. Quando in PHP riempi un array nativo e lo superi, l'engine deve riallocare un blocco di memoria grande il doppio e copiare tutti gli elementi. SplFixedArray non ha questo comportamento implicito, lasciando a te il controllo dell'allocazione.

Inoltre, con PHP 8.0, SplFixedArray è stato modernizzato. Ha abbandonato l'implementazione dell'interfaccia Iterator a favore di IteratorAggregate, il che significa che il ciclo foreach interno ora utilizza lo stesso iteratore ad alte prestazioni degli array nativi, abbassando notevolmente l'overhead.

Come si scrive

La sintassi è estremamente pulita e orientata agli oggetti. A differenza degli array classici che crescono magicamente, qui devi dichiarare le tue intenzioni fin dal principio.

// Inizializziamo un array fisso di 100.000 elementi
$size = 100000;
$fixedArray = new SplFixedArray($size);

// L'assegnazione avviene come in un array normale
for ($i = 0; $i < $size; $i++) {
    $fixedArray[$i] = $i * 2;
}

// Lettura e iterazione
foreach ($fixedArray as $key => $value) {
    // Elaborazione rapida
}

La rigidità di SplFixedArray è il suo punto di forza. Se provi ad accedere a un indice non valido o a utilizzare una chiave stringa, PHP ti punirà immediatamente, lanciando un'eccezione (RuntimeException o InvalidArgumentException).

$arr = new SplFixedArray(5);
$arr['chiave_testo'] = 'valore'; // Fatal error: Uncaught TypeError
$arr[10] = 'valore'; // Fatal error: Uncaught RuntimeException: Index invalid or out of range

Questo comportamento, in un'architettura enterprise rigorosa, è un grande vantaggio: agisce come un meccanismo di fail-fast naturale che impedisce la creazione involontaria di chiavi anomale derivanti da bug logici.

Dimensioni e conversioni

Cosa succede se, nonostante la "fissità", ti accorgi di aver bisogno di più spazio? Puoi ridimensionare l'oggetto tramite il metodo setSize().

$arr = new SplFixedArray(10);
$arr->setSize(20); // Aumenta lo spazio mantenendo i dati precedenti
$arr->setSize(5);  // Tronca l'array, eliminando gli elementi oltre l'indice 4

Bisogna fare attenzione: chiamare setSize() non è una pratica indolore.... Internamente l'engine C dovrà allocare nuova memoria e spostare i dati. Se ti trovi a chiamare `setSize` ripetutamente in un ciclo significa che stai usando lo strumento sbagliato e faresti meglio ad affidarti a un array normale.

La SPL mette anche a disposizione metodi rapidi per muoversi da e verso il mondo degli array classici:

$nativeArray = [1, 2, 3, 4, 5];
$fixed = SplFixedArray::fromArray($nativeArray, false); // il secondo parametro disabilita il salvataggio delle chiavi originali per maggiore velocità

$backToNative = $fixed->toArray();

Analisi della memoria

Sviluppando sistemi complessi in PHP, specialmente quando si toccano i confini del machine learning o dell'indicizzazione testuale, i benchmark diventano cruciali.

Immaginiamo di dover caricare in memoria un milione di stringhe per processarle (un po' come avviene quando si fa chunking di documenti per generare vettori).

Un array nativo impacchettato (packed array) di 1.000.000 di interi in PHP 8.3 consuma circa 32 MB di RAM. Uno SplFixedArray equivalente consuma circa 24 MB.

Il risparmio di circa il 25% sulla memoria è ancora reale e tangibile. Se la tua applicazione elabora decine di queste strutture contemporaneamente, la differenza tra l'uso di SplFixedArray o array classici potrebbe essere la differenza tra un processo che va in Out of Memory e uno che completa il task senza problemi.

A livello di velocità di iterazione foreach, comunque, l'array nativo potrebbe battere SplFixedArray di qualche decina di millisecondi a causa del modo in cui lo Zend Engine è ottimizzato, ma SplFixedArray vincerà sempre sul picco di memoria allocata.

Best practices

Dopo anni di utilizzo, ecco le mie raccomandazioni per chi vuole integrare questa classe nei propri progetti:

Cosa NON fare:

Cosa FARE:

In conclusione

PHP si è evoluto in modo straordinario. Da linguaggio per semplici script di template è diventato un motore robusto capace di eseguire calcoli pesanti, far girare demoni a vita lunga (grazie a Swoole, RoadRunner o FrankenPHP) e gestire carichi di lavoro enormi.

In questo ecosistema moderno, tornare alle basi è vitale. Imparare a usare strumenti come SplFixedArray ci ricorda che, sotto tutte le astrazioni e le sintassi moderne, stiamo ancora lavorando con una macchina che richiede CPU e RAM.

Sapere quando utilizzare una Hash Table (l'array standard) e quando invece optare per una memoria contigua (SplFixedArray) è esattamente quel salto di consapevolezza ingegneristica che separa uno script che "semplicemente funziona" da un software progettato per scalare. Continuiamo a scrivere codice consapevole!