Как правильно работать с большим массивом: создавать новый или перезаписывать элементы старого?

Question

[Shimpanze]

Есть огромный массив данных, который в процессе работы с ним, полностью! перезаписывается.

Что выгоднее всего: удалять каждый элемент массива через unset(), а затем вставлять на его место новый элемент, или сразу создавать новый массив.

Что выгоднее с точки зрения экономии памяти и потребления ресурсов сервера?

Comments

[Adamos]

Потоковое чтение данных и формирование объекта на лету вместо работы с "огромным массивом".

[Дмитрий]

https://www.php.net/manual/ru/spl.datastructures.php

[Ипатьев]

а зачем удалять через unset()?

[galliard]

Дмитрий, а я слышал, что это расширение устарело и работает медленнее обычных массивов.

[Дмитрий]

galliard, не думаю что медленнее, может так же, просто это стандартная библиотека, еще в 5 запилили, потом пых сильно перелопатили, надо смотреть сравнивать, может и так

[galliard]

Дмитрий, ну я сам тоже не тестил, читал где-то, давно уже, просто запомнилось.

Answer 1

[alexalexes]

Выгоднее всего положить в базу данных, которая специализируется на ключ-значении данных, типа redis или memcached и там делать манипуляции - они на этом специализируются.
Если с массивом работать напрямую, то выгоднее изменять существующий массив, в изменяющие функции передавать массив по ссылке, следить, чтобы методы при изменении массива не создавали новый массив, а работали с существующим.
Будут провалы производительности у границ количества элементов кратные степени двойки (ссылка). Это плата за высокоуровневые фишки в виде ресайза массива, чего нет на низком уровне реализации интерпретатора PHP.

Comments

[Vitsliputsli]

Будут провалы производительности у границ количества элементов кратные степени двойки. Это плата за высокоуровневые фишки в виде ресайза массива, чего нет на низком уровне реализации интерпретатора PHP.

А что за низкий уровень реализации?

[alexalexes]

Имеется ввиду низкоуровневые языки программирования C/C++. На чем реализованы модули PHP сервера.
В этих языках нельзя на ходу переопределить емкость массива, приходится придумывать стратегию расширения массива до определенного порога элементов. Эти моменты расширения массивов и видны в бенчмарках, если замерять память и время выполнения скрипта при добавлении элементов в массив.

[Vitsliputsli]

alexalexes, а вы про это, ну не совсем так. Сишные массивы, про которые вы пишите, фиксированного размера и при необходимости их расширения придется создавать новый и заполнять его - разумеется это очень дорого. PHP-стандартные массивы устроены совершенно по-другому, копирование данных при их расширении не нужно, поэтому в php - расширение проходит дешево. Да, нет гарантии, что любое добавление элемента выполнится за одно и тоже минимальное время, как вы правильно заметили, некоторые добавления происходят дольше - в этих случаях идет перестройка хеш-таблицы, да, это относительно не быстро на больших таблицах, но и не провал производительности как было бы при пересоздании всего массива.

[Александр Вялых]

Vitsliputsli, если мне не изменяет память, в PHP это как раз проблема скачков по памяти, когда создаешь массив, то под капотом создается массив определенного размера, потому что он не может быть бесконечным в любом случае. При расширении массива, когда упираемся в размер, PHP создает новый массив бОльшего размера и копирует туда значения из старого.

[Vitsliputsli]

Александр Вялых, извиняюсь, если ввел в заблуждение, проверил, да, вы и alexalexes правы, еще в 7ке zval перетащили в bucket, а bucket в arData. А я то считал, что как раньше данные php-шного массива лежат отдельно. А так, у нас один сишный массив на который ссылается хештаблица, и прям в нем лежит zval (понятно, что zval не обязательно уже данные, но все же).
Т.е. при rehash, необходимо перестроить хештаблицу и не просто массив с указателями, а массив со сложной структурой. Одно дело скопировать массив с интами, а другое дело с структурой, где только интов целая гора. Но, видно это меньшее из зол.