Mail.ru Group corporate blog
Website development
PHP
Compilers
Comments 14
0
Такая довольно хорошая статья, что добавить даже нечего.

> Одни варианты лучше при добавлении данных, другие — при поиске и т. д. Выбирайте реализацию в зависимости от того, что для вас важнее.
А не могли бы вы, пожалуйста, дать ссылку на переведенный материал? Думаю, не мне одному будет это полезно, т.к. Хабр всё-же русскоязычный, а те, кто осиливает разъяснение hash-таблиц на английском — тем и статья на Хабре не нужна

А вот еще вопрос — массивы, содержащие в себе объекты — подвергаются ли оптимизации, и как их лучше оптимизировать? Или это уже будет экономия на спичках, т.к. сам объект жрёт больше? Или я не прав?
+1
Ссылка же есть под постом, рядом с ником автора: http://jpauli.github.io/2016/04/08/hashtables.html
0
Вы не правы. Объекты жрут меньше, чем массивы: https://gist.github.com/nikic/5015323
Данный пост верен для PHP5. Для PHP7 легко проверить самостоятельно. Но, забегая вперёд, скажу, что объекты в PHP7 всё-равно занимают меньше памяти, чем массивы.
0
> размер таблицы всегда равен двойке в степени. Это делается для улучшения производительности и выравнивания размещения данных в памяти

Думается, выравнивание в данном случае — последнее, что может иметь значение :) Степень двойки в качестве размера хороша тем, что при изменении размера таблицы значение сжатого по модулю хэша ключа изменяется ровно на 1 бит. И при перераспределении элементов мы просто не будем трогать те, у которых дополнительный бит нулевой — они и так уже на своём месте.
0
Насколько я понимаю это может быть важно если у нас много небольших массивов
0
В эрланге тип данных map, который делает то же самое, проектировали года 4 не меньше.

Важные вопросы были: как сделать эффективным передачу между тредами, как сделать эффективным создание копии хеша, но с удаленными элементами:

Map2 = maps:without(mykey, Map1)

Тут об этом думали?
0
Ну почему же. В одном потоке можно ждать агрегацию данных в базе, а в другом тем временем собирать некую картинку.
0
И отвалиться по таймауту web-сервера и не отдать пользователю ни результат агрегации, ни картинку.

Я категорически рад, что в php нет нативной многопоточности, что уменьшает во мне искушение совмещать несовместимые задачи в одном запросе.
0
Если на С++ можно выстрелить в ногу, то это не значит, что на нём не надо писать. А думать головой кому прописано? Потоки — это хорошо.
0
Никто и не говорит, что потоки — это плохо. Но если возникает необходимость вести параллельные вычисления совершенно разных типов данных в рамках одного логического куска, то это свидетельствует о том, что выстрел в ногу уже произошел и вполне уже можно выстрелить себе в голову пытаясь покрыть костылями существующую архитектуру.

А там, где многопоточность действительно оправдана, вполне подойдет переброс запроса в соседний сервис, который для этого будет специально написан на чем-то более дружелюбном к потокам.
0

Скажи, пожалуйста, как можно запустить куски кода из статьи в качестве отдельного си приложения?

Only those users with full accounts are able to leave comments.  , please.