Lista de funções Big-O para PHP

Depois de usar o PHP há algum tempo, notei que nem todas as funções embutidas do PHP são tão rápidas quanto o esperado. Considere estas duas implementações possíveis de uma função que descobre se um número é primo usando uma matriz de números primos em 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 );
}

Isso ocorre porque in_arrayé implementado com uma pesquisa linear O (n) que diminui linearmente à medida que $prime_arraycresce. Onde a array_key_existsfunção é implementada com uma pesquisa de hash O (1), que não diminui a velocidade, a menos que a tabela de hash seja extremamente preenchida (nesse caso, é apenas O (n)).

Até agora, tive que descobrir os grandes Os por tentativa e erro, e ocasionalmente olhando o código-fonte . Agora, a pergunta ...

Existe uma lista dos grandes tempos teóricos (ou práticos) para todas as * funções embutidas do PHP?

* ou pelo menos os interessantes

Por exemplo, acho que é muito difícil prever o grande O de funções listadas porque a possível implementação depende de estruturas de dados do núcleo desconhecido do PHP: array_merge, array_merge_recursive, array_reverse, array_intersect, array_combine,str_replace (com entradas de matriz), etc.

Como não parece que alguém tenha feito isso antes, pensei que seria uma boa ideia tê-lo como referência em algum lugar. Eu fui embora e via benchmark ou skimming de código para caracterizar oarray_* funções. Eu tentei colocar o Big-O mais interessante perto do topo. Está lista não está completa.

Nota: Todo o Big-O foi calculado assumindo uma pesquisa de hash é O (1), embora seja realmente O (n). O coeficiente de n é tão baixo que a sobrecarga de memória RAM de armazenar uma matriz grande o suficiente o prejudicaria antes que as características da pesquisa Big-O começassem a surtir efeito. Por exemplo, a diferença entre uma chamada paraarray_key_exists N = 1 e N = 1.000.000 é de aproximadamente 50% de aumento de tempo.

Pontos interessantes :

1. isset/ array_key_existsé muito mais rápido que in_arrayearray_search
2. +(união) é um pouco mais rápido que array_merge(e parece melhor). Mas funciona de maneira diferente, portanto, lembre-se disso.
3. shuffle está no mesmo nível Big-O que array_rand
4. array_pop/array_push é mais rápido que array_shift/ array_unshiftdevido à re-indexação da penalidade

Pesquisas :

array_key_existsO (n), mas realmente próximo de O (1) - isso ocorre por causa de pesquisas lineares em colisões, mas como a chance de colisões é muito pequena, o coeficiente também é muito pequeno. Acho que você trata as pesquisas de hash como O (1) para fornecer um big-O mais realista. Por exemplo, a diferença entre N = 1000 e N = 100000 é apenas cerca de 50% mais lenta.

isset( $array[$index] )O (n), mas realmente próximo de O (1) - ele usa a mesma pesquisa que array_key_exists. Como é uma construção de idioma, a pesquisa será armazenada em cache se a chave for codificada, resultando em aceleração nos casos em que a mesma chave for usada repetidamente.

in_array O (n) - isso ocorre porque ele faz uma pesquisa linear pela matriz até encontrar o valor.

array_search O (n) - usa a mesma função principal que in_array, mas retorna valor.

Funções de fila :

array_push O (∑ var_i, para todos os i)

array_pop O (1)

array_shift O (n) - ele precisa reindexar todas as chaves

array_unshift O (n + ∑ var_i, para todos os i) - ele precisa reindexar todas as chaves

Intersecção, União, Subtração da Matriz :

array_intersect_key se a interseção 100% fizer O (Max (param_i_size) * ∑param_i_count, para todos os i), se a interseção 0% interceptar O (∑param_i_size, para todos os i)

array_intersect se a interseção 100% fizer O (n ^ 2 * amparam_i_count, para todos os i), se a interseção 0% interceptar O (n ^ 2)

array_intersect_assoc se a interseção 100% fizer O (Max (param_i_size) * ∑param_i_count, para todos os i), se a interseção 0% interceptar O (∑param_i_size, para todos os i)

array_diff O (π param_i_size, para todos os i) - Esse é o produto de todos os param_sizes

array_diff_key O (∑ param_i_size, para i! = 1) - isso ocorre porque não precisamos iterar sobre a primeira matriz.

array_merge O (∑ matriz_i, i! = 1) - não precisa iterar sobre a primeira matriz

+ (union) O (n), onde n é o tamanho da segunda matriz (ou seja, array_first + array_second) - menos sobrecarga que array_merge, pois não precisa renumerar

array_replace O (∑ matriz_i, para todos os i)

Aleatório :

shuffle Em)

array_rand O (n) - Requer uma pesquisa linear.

Big-O óbvio :

array_fill Em)

array_fill_keys Em)

range Em)

array_splice O (deslocamento + comprimento)

array_slice O (deslocamento + comprimento) ou O (n) se comprimento = NULL

array_keys Em)

array_values Em)

array_reverse Em)

array_pad O (tamanho do bloco)

array_flip Em)

array_sum Em)

array_product Em)

array_reduce Em)

array_filter Em)

array_map Em)

array_chunk Em)

array_combine Em)

Gostaria de agradecer à Eureqa por facilitar a localização do Big-O das funções. É um programa gratuito incrível que pode encontrar a melhor função de ajuste para dados arbitrários.

EDITAR:

Para aqueles que duvidam que as pesquisas de matriz PHP sejam O(N), escrevi uma referência para testar isso (elas ainda são efetivamente O(1)para os valores mais realistas).

$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 );
}

A explicação para o caso que você descreve especificamente é que matrizes associativas são implementadas como tabelas de hash - portanto, procure por chave (e, correspondentemente, array_key_exists ) é O (1). No entanto, matrizes não são indexadas por valor, portanto, a única maneira de descobrir se existe um valor na matriz é uma pesquisa linear. Não há nenhuma surpresa lá.

Eu não acho que exista documentação abrangente específica da complexidade algorítmica dos métodos PHP. No entanto, se é uma preocupação grande o suficiente para justificar o esforço, você sempre pode procurar no código-fonte .

Você quase sempre deseja usar em issetvez de array_key_exists. Não estou olhando para os internos, mas tenho certeza de que array_key_existsé O (N) porque itera sobre todas as chaves da matriz, enquantoisset tenta acessar o elemento usando o mesmo algoritmo de hash usado quando você acessa um índice de matriz. Isso deve ser O (1).

Um "truque" a ser observado é o seguinte:

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

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

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

Fiquei curioso, por isso comparei a diferença:

<?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 segundos
array_key_exists:2.33202195168 segundos

Obviamente, isso não mostra a complexidade do tempo, mas mostra como as duas funções se comparam.

Para testar a complexidade do tempo, compare a quantidade de tempo necessária para executar uma dessas funções na primeira e na última chave.

Se as pessoas estivessem enfrentando problemas na prática com colisões importantes, implementariam contêineres com uma pesquisa secundária de hash ou uma árvore equilibrada. A árvore balanceada daria O (log n) ao pior caso e O (1) avg. case (o próprio hash). A sobrecarga não vale a pena na maioria das aplicações práticas em memória, mas talvez haja bancos de dados que implementem essa forma de estratégia mista como seu caso padrão.