Производительность системы обмена сообщениями?

Question

[floppa322]

Всем привет :)
В набирающем популярность фреймворке - Vert.x(TCP/UDP сервер) в качестве потокобезопасной коллекции для обмена сообщениями используется copy on write array. Коллекция предназначена для обмена сообщениями между некоторыми абстракциями фреймворка, работающими в разных потоках. Типичный юз кейс сообщения: на абстракцию-Http-сервер приходит запрос, требующий обращений в БД -> Http-сервер кладёт в коллекцию, скажем, id пользователя -> абстракция-БД забирает сообщение, обрабатывает и кладёт обратно -> Http-сервер забирает сообщение от БД и отдаёт ответ клиенту.

Как вы понимаете сообщений в единицу времени может быть очень много. А значит и операций вставки / удаления. В то время как copy on write коллекции предназначены для случаев с соотношением количества модификации / чтения данных близким к нулю.

Вопрос заключается в том, почему разработчики выбрали именно copy on write? Потому что в теории это должно работать очень медленно.

Сама коллекция

Answer 1

[Олег]

В теории, там тяжелая операция , только снятия элемента с головы очереди. Опять же в теории она может
оказаться выполняемой вместе с обновлением стекающего тока в микросхемах памяти.
На практике нужно глубоко покопаться в всех этих виртулизациях . А так операция копирования данных
в ОЗУ из одного места в другое , выполняется вспомогательными контролерами, а не АЛУ.
Сорри, что в терминах ранних процессоров.

Comments

[floppa322]

В теории, там тяжелая операция , только снятия элемента с головы очереди.

Не могли бы Вы по подробнее, пожалуйста

А так операция копирования данных
в ОЗУ из одного места в другое , выполняется вспомогательными контролерами, а не АЛУ

Ну классический способ скопировать массив - прочитать данные в регистр процессора, затем записать данные из этого регистра в сегмент данных, то есть оперативную память .То есть есть ещё дополнительный способ скопировать данные из одного массива в другой помимо упомянутого раньше - тот, который Вы упомянули. Не могли бы Вы назвать, пожалуйста, ассемблерную команду для этого
Ну и в любом случае, если копировать данные без участия процессора бы всегда было выгодно, то по такой логике только copy on write реализацию конкурентные коллекции бы и имели.

[Олег]

bakdurak, narodstream.ru/stm-urok-155-hal-dma-mem2mem
А может быть выполнено и так.

Но в данном случае я все же думаю резоны были такие.
Первое правило . НЕ ЗАНИМАТЬСЯ ПРЕЖДЕВРЕМЕННОЙ ОПТИМИЗАЦИЕЙ
До завершения проекта и его начала промышленно-тестовой эксплуатации
понять где возникнет бутылочное горлышко не возможно.

[floppa322]

Олег, Благодарю за ссылку