Работа с размером блока deque вызывает проблемы с производительностью
Любой, кто использовал «deque» в критичном к производительности коде, вероятно, заметил это (по крайней мере, в STL, поставляемом с VS2010), что размер блока составляет 16 байтов. Это фактический фрагмент из заголовочного файла, поставляемого с VS2010:
#define _DEQUESIZ (sizeof (value_type) <= 1 ? 16 \
: sizeof (value_type) <= 2 ? 8 \
: sizeof (value_type) <= 4 ? 4 \
: sizeof (value_type) <= 8 ? 2 \
: 1) /* elements per block (a power of 2) */
Это не новая информация, смотрите О Деке<T>лишняя косвенность для более подробной информации о том, почему этот decl вызывает проблемы с производительностью.
Я хотел бы использовать deque в различных алгоритмах, но не если я ограничен этой реализацией. Какой лучший способ обойти эту проблему?
1) Используйте другой контейнер, у которого нет этой проблемы. Если это так, может кто-нибудь указать мне на тот, который не имеет лицензионных ограничений GNU?
2) Создайте новый контейнерный класс, который устраняет это ограничение. Этот новый контейнерный класс не будет частью пространства имен std.
3) Отредактируйте определение _DEQUESIZ в заголовочном файле deque. ИМО, я думаю, что это законно, поскольку точная спецификация _DEQUESIZ не является частью концепции deque, как определено в STL.
4) Добавьте дополнительный параметр шаблона в deque (и связанные классы итераторов), чтобы разрешить указание размера блока во время компиляции. Этот параметр по умолчанию будет соответствовать текущему определению _DEQUESIZ. Я в значительной степени отвергаю это решение, так как теперь мой код, использующий этот убогий STL, не переносим.
5) Лобби-конгресс, чтобы изменить STL, чтобы я мог с удовольствием использовать «deque» без проблем с производительностью. ИМО, это может иметь больший успех, чем текущие дебаты о финансовом обрыве. Кстати, я канадец, так что весь рингмол в палате представителей Сената и Президента сбивает с толку.
Решение
Не совсем ответ, но слишком долго для комментария:
Я бы не рекомендовал писать новый контейнерный класс, если вы беспокоитесь о производительности. Обычно реализации STL используют непереносимые оптимизации, основанные на деталях реализации конкретного компилятора, на который они нацелены, и вы, как правило, не сможете этого сделать. Однажды я попытался переписать несколько довольно простых алгоритмов STL и получить скорость выполнения примерно вдвое меньше.
изменения _DEQUESIZ вероятно, приведет к проблемам с производительностью в непредвиденных местах, потому что другой код может быть оптимизирован для исходного значения. Еще раз, вид непереносимых оптимизаций, которые вы можете выполнять, когда пишете код для конкретного компилятора. Не только это: вы можете даже сломать некоторый код, который зависит от фактического значения _DEQUESIZ,
В целом, только мой вариант 1 выделяется как осуществимый, по моему мнению. К сожалению, я не знаю ни одного хорошего варианта, чтобы предложить; Вот почему я написал, что это не реальный ответ на вашу проблему.
Другие решения
Я бы предпочел 1).
Реализация библиотеки libc ++ Стандартной библиотеки распространяется по очень либеральной лицензии, достаточно либеральной на самом деле, что вы можете настроить ее, чтобы адаптировать ее, если ваш компилятор захлебнется ею (она была разработана на основе Clang, который гораздо более совместим и C ++ 11 в курсе чем VS 2010). Вам нужно только сохранить лицензию.
detector