Elenco di Big-O per funzioni PHP

Dopo aver usato PHP per un po 'di tempo, ho notato che non tutte le funzioni PHP integrate sono veloci come previsto. Considera queste due possibili implementazioni di una funzione che rileva se un numero è primo usando una matrice di numeri primi memorizzata nella cache.

//very slow for large $prime_array
$prime_array = array( 2, 3, 5, 7, 11, 13, .... 104729, ... );
$result_array = array();
foreach( $prime_array => $number ) {
    $result_array[$number] = in_array( $number, $large_prime_array );
}

//speed is much less dependent on size of $prime_array, and runs much faster.
$prime_array => array( 2 => NULL, 3 => NULL, 5 => NULL, 7 => NULL,
                       11 => NULL, 13 => NULL, .... 104729 => NULL, ... );
foreach( $prime_array => $number ) {
    $result_array[$number] = array_key_exists( $number, $large_prime_array );
}

Questo perché in_arrayè implementato con una ricerca lineare O (n) che rallenterà linearmente man mano che $prime_arraycresce. Dove ilarray_key_exists funzione è implementata con una ricerca hash O (1) che non rallenterà a meno che la tabella hash non sia estremamente popolata (nel qual caso è solo O (n)).

Finora ho dovuto scoprire i big-O tramite tentativi ed errori, e occasionalmente guardando il codice sorgente . Ora per la domanda ...

Esiste un elenco dei grandi O teorici (o pratici) per tutte le * funzioni PHP integrate?

* o almeno quelli interessanti

Ad esempio, trovo molto difficile prevedere il grande O di funzioni elencate perché la possibile implementazione dipende strutture di dati Sconosciuto fondamentali di PHP: array_merge, array_merge_recursive, array_reverse, array_intersect, array_combine, str_replace(con ingressi matrice), etc.

Dal momento che non sembra che nessuno l'abbia fatto prima ho pensato che sarebbe stata una buona idea averlo come riferimento da qualche parte. Ci sono passato e tramite benchmark o skoding di codice per caratterizzare ilarray_* funzioni. Ho provato a mettere il Big-O più interessante vicino alla cima. Questo elenco non è completo.

Nota: Tutti i Big-O dove calcolati assumendo una ricerca hash è O (1) anche se in realtà è O (n). Il coefficiente di n è così basso che l'overhead del ram di memorizzare un array abbastanza grande ti danneggerebbe prima che le caratteristiche della ricerca Big-O iniziassero ad avere effetto. Ad esempio, la differenza tra una chiamata array_key_existsa N = 1 e N = 1.000.000 è un aumento del tempo del 50% circa.

Punti interessanti :

1. isset/ array_key_existsè molto più veloce di in_arrayearray_search
2. +(unione) è un po 'più veloce di array_merge(e sembra più bello). Ma funziona in modo diverso, quindi tienilo a mente.
3. shuffle è sullo stesso livello Big-O di array_rand
4. array_pop/ array_pushè più veloce di array_shift/ a array_unshiftcausa della penalità di reindicizzazione

Ricerche :

array_key_existsO (n) ma molto vicino a O (1) - questo è dovuto al polling lineare nelle collisioni, ma poiché la possibilità di collisioni è molto piccola, anche il coefficiente è molto piccolo. Trovo che tratti le ricerche di hash come O (1) per dare un big-O più realistico. Ad esempio, la differenza tra N = 1000 e N = 100000 rallenta solo del 50% circa.

isset( $array[$index] )O (n) ma molto vicino a O (1) - utilizza la stessa ricerca di array_key_exists. Poiché è il costrutto del linguaggio, memorizzerà nella cache la ricerca se la chiave è codificata, aumentando la velocità nei casi in cui la stessa chiave viene utilizzata ripetutamente.

in_array O (n) - questo perché esegue una ricerca lineare nell'array fino a quando non trova il valore.

array_search O (n): utilizza la stessa funzione principale di in_array ma restituisce valore.

Funzioni di coda :

array_push O (∑ var_i, per tutti i)

array_pop O (1)

array_shift O (n) - deve reindicizzare tutte le chiavi

array_unshift O (n + ∑ var_i, per tutti i) - deve reindicizzare tutte le chiavi

Intersezione di array, unione, sottrazione :

array_intersect_key se intersezione 100% fa O (Max (param_i_size) * ∑param_i_count, per tutti i), se intersezione 0% interseca O (∑param_i_size, per tutti i)

array_intersect se l'intersezione 100% fa O (n ^ 2 * ∑param_i_count, per tutti i), se l'intersezione 0% interseca O (n ^ 2)

array_intersect_assoc se intersezione 100% fa O (Max (param_i_size) * ∑param_i_count, per tutti i), se intersezione 0% interseca O (∑param_i_size, per tutti i)

array_diff O (π param_i_size, per tutti i) - Questo è il prodotto di tutti i param_sizes

array_diff_key O (∑ param_i_size, per i! = 1) - questo perché non è necessario eseguire l'iterazione sul primo array.

array_merge O (∑ array_i, i! = 1) - non è necessario scorrere il primo array

+ (unione) O (n), dove n è la dimensione del secondo array (ovvero array_first + array_second) - meno sovraccarico di array_merge poiché non deve rinumerare

array_replace O (∑ array_i, per tutti i)

Casuale :

shuffle Su)

array_rand O (n) - Richiede un sondaggio lineare.

Ovvio Big-O :

array_fill Su)

array_fill_keys Su)

range Su)

array_splice O (offset + lunghezza)

array_slice O (offset + lunghezza) o O (n) se lunghezza = NULL

array_keys Su)

array_values Su)

array_reverse Su)

array_pad O (pad_size)

array_flip Su)

array_sum Su)

array_product Su)

array_reduce Su)

array_filter Su)

array_map Su)

array_chunk Su)

array_combine Su)

Vorrei ringraziare Eureqa per aver reso facile trovare il Big-O delle funzioni. È un fantastico gratuito programma in grado di trovare la migliore funzione di adattamento per dati arbitrari.

MODIFICARE:

Per coloro che dubitano che lo siano le ricerche di array PHP O(N), ho scritto un benchmark per testarlo (sono ancora efficaci O(1)per valori più realistici).

$tests = 1000000;
$max = 5000001;


for( $i = 1; $i <= $max; $i += 10000 ) {
    //create lookup array
    $array = array_fill( 0, $i, NULL );

    //build test indexes
    $test_indexes = array();
    for( $j = 0; $j < $tests; $j++ ) {
        $test_indexes[] = rand( 0, $i-1 );
    }

    //benchmark array lookups
    $start = microtime( TRUE );
    foreach( $test_indexes as $test_index ) {
        $value = $array[ $test_index ];
        unset( $value );
    }
    $stop = microtime( TRUE );
    unset( $array, $test_indexes, $test_index );

    printf( "%d,%1.15f\n", $i, $stop - $start ); //time per 1mil lookups
    unset( $stop, $start );
}

La spiegazione del caso che descrivi specificamente è che gli array associativi sono implementati come tabelle hash, quindi cerca per chiave (e, di conseguenza, array_key_exists ) è O (1). Tuttavia, le matrici non sono indicizzate per valore, quindi l'unico modo per scoprire se esiste un valore nella matrice è una ricerca lineare. Non c'è sorpresa lì.

Non credo che ci sia una documentazione completa specifica della complessità algoritmica dei metodi PHP. Tuttavia, se è una preoccupazione abbastanza grande da giustificare lo sforzo, puoi sempre consultare il codice sorgente .

Hai quasi sempre voglia di usare issetinvece di array_key_exists. Non sto guardando gli interni, ma sono abbastanza sicuro che array_key_existssia O (N) perché scorre su ogni chiave dell'array, mentreisset cerca di accedere all'elemento usando lo stesso algoritmo hash che viene utilizzato quando si accede un indice di array. Dovrebbe essere O (1).

Un "gotcha" a cui prestare attenzione è questo:

$search_array = array('first' => null, 'second' => 4);

// returns false
isset($search_array['first']);

// returns true
array_key_exists('first', $search_array);

Ero curioso, quindi ho confrontato la differenza:

<?php

$bigArray = range(1,100000);

$iterations = 1000000;
$start = microtime(true);
while ($iterations--)
{
    isset($bigArray[50000]);
}

echo 'is_set:', microtime(true) - $start, ' seconds', '<br>';

$iterations = 1000000;
$start = microtime(true);
while ($iterations--)
{
    array_key_exists(50000, $bigArray);
}

echo 'array_key_exists:', microtime(true) - $start, ' seconds';
?>

is_set:0,132308959961 secondi
array_key_exists:2,33202195168 secondi

Naturalmente, questo non mostra la complessità temporale, ma mostra come le 2 funzioni si confrontano tra loro.

Per verificare la complessità temporale, confrontare il tempo necessario per eseguire una di queste funzioni sul primo tasto e sull'ultimo tasto.

Se in pratica le persone avessero dei problemi con le collisioni chiave, implementerebbero contenitori con una ricerca hash secondaria o un albero bilanciato. L'albero bilanciato darebbe O (log n) comportamento peggiore e O (1) avg. case (l'hash stesso). Il sovraccarico non vale la pena nella maggior parte dei casi pratici nelle applicazioni di memoria, ma forse ci sono database che implementano questa forma di strategia mista come il loro caso predefinito.