Список Big-O для функцій PHP

Протягом деякого часу користуючись PHP, я помітив, що не всі вбудовані функції PHP такі швидкі, як очікувалося. Розглянемо ці дві можливі реалізації функції, яка визначає, чи є число простим, використовуючи кешований масив простих чисел.

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

Це тому in_array, що реалізується за допомогою лінійного пошуку O (n), який лінійно сповільнюватиметься у міру $prime_arrayзростання. Якщо array_key_existsфункція реалізована з пошуковим пошуком O (1), який не сповільниться, якщо хеш-таблиця не буде надзвичайно заповнена (у такому випадку це лише O (n)).

Поки що мені доводилося виявляти великі-O через проби та помилки, а також час від часу переглядаючи вихідний код . Тепер для питання ...

Чи є перелік теоретичних (або практичних) великих O-часів для всіх * вбудованих функцій PHP?

* або принаймні цікавого

Наприклад, я вважаю , це дуже важко передбачити , великий O функцій , перерахованих , так як можлива реалізація залежить від невідомих основних структур даних PHP: array_merge, array_merge_recursive, array_reverse, array_intersect, array_combine, str_replace(з входами масиву), і т.д.

Оскільки не здається, що хтось робив це раніше, ніж я подумав, що було б добре мати його десь для довідки. Я хотів і хоч і через еталонний або кодовий режим для характеристики array_*функцій. Я намагався поставити більш цікавий Big-O біля вершини. Цей список не є повним.

Примітка: Усі великі-O, де обчислюються при допущенні пошуку хешу, є O (1), хоча це дійсно O (n). Коефіцієнт n настільки низький, накладні накладні витрати на зберігання достатньо великого масиву зашкодять вам до того, як характеристики пошуку Big-O почнуть діяти. Наприклад, різниця між викликом до array_key_existsN = 1 і N = 1 000 000 - це ~ 50% збільшення часу.

Цікаві бали :

1. isset/ array_key_existsнабагато швидше ніж in_arrayіarray_search
2. +(союз) трохи швидше, ніж array_merge(і виглядає приємніше). Але це працює інакше, тому майте це на увазі.
3. shuffle знаходиться на тому ж рівні Big-O array_rand
4. array_pop/ array_pushшвидше, ніж array_shift/ array_unshiftвнаслідок повторного покарання

Пошуки :

array_key_existsO (n), але насправді близький до O (1) - це через лінійне опитування при зіткненнях, а тому, що шанс зіткнень дуже малий, коефіцієнт також дуже малий. Я вважаю, що ви розглядаєте хеш-купе як O (1), щоб отримати більш реалістичний big-O. Наприклад, різниця між N = 1000 і N = 100000 - це лише близько 50% сповільнення.

isset( $array[$index] )O (n), але дійсно близький до O (1) - він використовує той самий пошук, що і array_key_exists. Оскільки це мовна конструкція, кешуватиме пошук, якщо ключ жорстко закодований, що призведе до прискорення у випадках, коли одна і та ж клавіша використовується неодноразово.

in_array O (n) - це тому, що він виконує лінійний пошук через масив, поки не знайде значення.

array_search O (n) - він використовує ту саму основну функцію, що і in_array, але повертає значення.

Функції черги :

array_push O (∑ var_i, для всіх i)

array_pop O (1)

array_shift O (n) - він повинен перевстановити всі клавіші

array_unshift O (n + ∑ var_i, для всіх i) - він повинен повторно встановити всі клавіші

Перетин перетину, об'єднання, віднімання :

array_intersect_key якщо перетин 100% зробимо O (Макс (param_i_size) * ∑param_i_count, для всіх i), якщо перетин 0% перетинається O (∑param_i_size, для всіх i)

array_intersect якщо перетин 100% зробіть O (n ^ 2 * ∑param_i_count, для всіх i), якщо перетин 0% перетинається O (n ^ 2)

array_intersect_assoc якщо перетин 100% зробимо O (Макс (param_i_size) * ∑param_i_count, для всіх i), якщо перетин 0% перетинається O (∑param_i_size, для всіх i)

array_diff O (π param_i_size, для всіх i) - Це добуток усіх параметри_розмірів

array_diff_key O (∑ param_i_size, для i! = 1) - це тому, що нам не потрібно повторювати перший масив.

array_merge O (∑ array_i, i! = 1) - не потрібно перебирати перший масив

+ (об'єднання) O (n), де n - розмір 2-го масиву (тобто array_first + array_second) - менший накладні витрати, ніж array_merge, оскільки він не повинен перенумеровувати

array_replace O (∑ array_i, для всіх i)

Випадкові :

shuffle O (n)

array_rand O (n) - вимагає лінійного опитування.

Очевидний Big-O :

array_fill O (n)

array_fill_keys O (n)

range O (n)

array_splice O (зміщення + довжина)

array_slice O (зміщення + довжина) або O (n), якщо довжина = NULL

array_keys O (n)

array_values O (n)

array_reverse O (n)

array_pad O (pad_size)

array_flip O (n)

array_sum O (n)

array_product O (n)

array_reduce O (n)

array_filter O (n)

array_map O (n)

array_chunk O (n)

array_combine O (n)

Я хотів би подякувати Eureqa за те, що вона легко знайшла Big-O з функцій. Це дивовижна безкоштовна програма, яка може знайти найкращу функцію пристосування для довільних даних.

Редагувати:

Для тих, хто сумнівається в пошуку масивів PHP O(N), я написав орієнтир, щоб перевірити це (вони все ще ефективно O(1)для більшості реалістичних значень).

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

Пояснення випадку, яке ви конкретно описуєте, полягає в тому, що асоціативні масиви реалізуються у вигляді хеш-таблиць, тому пошук за ключем (і, відповідно, array_key_exists) є O (1). Однак масиви не індексуються за значенням, тому єдиний спосіб у загальному випадку виявити, чи існує значення в масиві - це лінійний пошук. Тут немає ніякого сюрпризу.

Я не думаю, що існує специфічна вичерпна документація алгоритмічної складності методів PHP. Однак якщо це достатньо велика стурбованість, щоб докласти зусиль, ви завжди можете переглянути вихідний код .

Ви майже завжди хочете використовувати issetзамість цього array_key_exists. Я не дивлюся на внутрішні, але я впевнений, що array_key_existsце O (N), оскільки він ітералізує кожну клавішу масиву, тоді якisset намагається отримати доступ до елемента за допомогою того ж алгоритму хешу, який використовується під час доступу індекс масиву Це має бути O (1).

Один з "gotcha", на який слід стежити:

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

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

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

Мені було цікаво, тому я визначив різницю:

<?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 секунд
array_key_exists: 2,33202195168 секунд

Звичайно, це не показує складності в часі, але воно показує, як дві функції порівнюють одна одну.

Щоб перевірити складність часу, порівняйте кількість часу, необхідного для запуску однієї з цих функцій на першій та останній клавішах.

Якщо люди натрапляли на проблеми на практиці при ключових зіткненнях, вони реалізовували б контейнери з вторинним пошуковим хешем або збалансованим деревом. Збалансоване дерево дало б O (log n) найгірший випадок і O (1) avg. справа (сам хеш). Накладні витрати не варто цього в більшості практичних програм для пам'яті, але, можливо, є бази даних, які реалізують цю форму змішаної стратегії як їх за замовчуванням.