Структура данных libev watchers

Ожидается, что для одного и того же fd (аналогично для сигналов) существует всего несколько (обычно один, и почти всегда максимум два) наблюдателя за вводом-выводом. Помещение ссылок списка в наблюдатель означает, что не требуется никаких дополнительных выделений, как это потребовалось бы, если бы для каждого наблюдателя использовался массив. Если бы на одном и том же fd было активно много наблюдателей за вводом-выводом, то этот подход со связанными списками был бы медленнее.

Массивы используются, потому что вставка и удаление выполняются очень быстро (наблюдатель сохраняет индекс массива). Использование 4-байтового индекса также снижает требования к памяти на 64-битных машинах (12 байтов на наблюдателя по сравнению, например, с 16 для двусвязного списка), а использование массива указателей означает, что все указатели находятся рядом друг с другом в памяти, что повышает эффективность кэширования при сканировании, что является частой операцией для некоторых наблюдателей.

Эффективность кэша также является причиной, по которой 4-куча используется вместо 2-кучи, и причиной, по которой значения времени копируются в структуру данных кучи, чтобы избежать доступа к памяти наблюдателя при операциях с кучей.

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

Вероятно, причина в том, что в типичном сценарии ev_io нужно искать с помощью fd. Базовая библиотека (epoll, select или что-то еще) предоставит fd с некоторым событием. Затем Либев просто использовал бы его как индекс и просто перебирал бы связанный список наблюдателей за событиями, которые необходимо вызвать. Так что это может быть быстро в огневых событиях.