Pull to refresh

Comments 14

Такая довольно хорошая статья, что добавить даже нечего.

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

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

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

Map2 = maps:without(mykey, Map1)

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

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

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

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

Sign up to leave a comment.