Мне очень не нравятся контейнеры STL, потому что они делают медленную версию моего кода отладки. Что используют другие люди вместо STL, которые имеют разумную производительность для отладочных сборников?
Я программист, и это было проблемой во многих проектах, над которыми я работал. Очень сложно получить 60 кадров в секунду, когда вы используете контейнер STL для всего.
Я использую MSVC для большей части моей работы.
EASTL - это возможность, но все же не идеальная. Пол Педриана из Electronic Arts провел исследование различных реализаций STL в отношении производительности в игровых приложениях, резюме которых можно найти здесь: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Некоторые из этих корректировок проверяются для включения в стандарт С++.
И обратите внимание, что даже EASTL не оптимизирует для неоптимизированного случая. У меня был файл excel с некоторым временем, но я думаю, что потерял его, но для доступа это было что-то вроде:
debug release
STL 100 10
EASTL 10 3
array[i] 3 1
Самый успешный опыт, который у меня был, - это прокатка собственных контейнеров. Вы можете получить их до почти массив [x].
Мой опыт в том, что хорошо продуманный STL-код медленно запускается в отладочных сборках, потому что оптимизатор отключен. Контейнеры STL выделяют много вызовов конструкторам и оператору = которые (если они имеют малый вес) встраиваются/удаляются в сборках релизов.
Кроме того, Visual С++ 2005 и выше имеют возможность проверки STL как в выпусках, так и для отладки. Это огромная производительность для программного обеспечения STL-heavy. Его можно отключить, указав _SECURE_SCL = 0 для всех ваших единиц компиляции. Обратите внимание, что наличие разных статусов _SECURE_SCL в разных единицах компиляции почти наверняка приведет к катастрофе.
Вы можете создать третью конфигурацию сборки с отключенной проверкой и использовать ее для отладки с производительностью. Я рекомендую вам сохранить конфигурацию отладки с проверкой, хотя, так как очень полезно улавливать ошибочные индексы массивов и тому подобное.
Если вы работаете с визуальными студиями, вы можете рассмотреть следующее:
#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0
Что только для итераторов, какие типы операций STL вы формируете? Вы можете посмотреть оптимизацию операций с памятью; т.е., используя resize(), чтобы вставить сразу несколько элементов вместо использования pop/push для вставки элементов по одному.
Для крупных приложений с высокой критичностью, создание собственных контейнеров, специально предназначенных для ваших нужд, может стоить времени.
Я говорю о реальном развитии игры здесь.
Готов поспорить, ваш STL использует проверенную реализацию для отладки. Вероятно, это хорошо, так как это приведет к перехвату итераторов и тому подобное. Если это для вас большая проблема, возможно, есть компилятор, чтобы отключить его. Проверьте свои документы.
Если вы используете Visual С++, вам следует взглянуть на это:
http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/
и ссылки с этой страницы, которые охватывают различные затраты и параметры всей проверки режима отладки, которые выполняет MS/Dinkware STL.
Если вы собираетесь задавать такой вопрос, зависящий от платформы, было бы неплохо также упомянуть вашу платформу...
Отъезд EASTL.
MSVC использует очень тяжелую реализацию проверенных итераторов в отладочных сборках, о которых другие уже говорили, поэтому я не буду повторять ее (но начинаю там)
Еще одна вещь, которая может вас заинтересовать, заключается в том, что ваша "сборка отладки" и "сборка релиза", вероятно, связаны с изменением (по крайней мере) 4 настроек, которые связаны только с неясными.
Они могут переключаться независимо. Первое не стоит ничего в производительности во время выполнения, хотя добавляет размер. Второй делает ряд функций более дорогими, но оказывает огромное влияние на malloc и бесплатно; версии отладки во время выполнения стараются "отравить" память, которую они касаются значениями, чтобы очистить неинициализированные ошибки данных. Я считаю, что с реализациями MSVCP * STL он также устраняет все пулы распределения, которые обычно выполняются, так что утечки показывают именно тот блок, который вы думаете, а не какой-то более крупный кусок памяти, который он выделял; это означает, что он делает больше вызовов для malloc поверх них намного медленнее. Третий; хорошо, что каждый делает много вещей (этот вопрос имеет хорошее обсуждение темы). К сожалению, это необходимо, если вы хотите, чтобы одношаговый режим работал плавно. Четвертое затрагивает множество библиотек по-разному, но наиболее примечательно, что он компилирует или отменяет assert() и друзей.
Итак, вы можете подумать о создании сборки с некоторой меньшей комбинацией этих выборов. Я много использую сборки, которые используют символы (/Zi и link/DEBUG), и утверждает (/DDEBUG), но все еще оптимизирован (/O1 или /O 2 или любые флаги, которые вы используете), но с указателями фреймов стека очистить обратные трассы (/Oy-) и использовать обычную библиотеку времени выполнения (/MT). Это выполняется близко к моей сборке релизов и является полуотверждаемым (обратные трассировки прекрасны, одноступенчатая игра немного путается на исходном уровне, а уровень сборки отлично работает). Вы можете иметь как можно больше конфигураций; просто клонируйте свой релиз и включите все части отладки, которые вам кажутся полезными.
Извините, я не могу оставить комментарий, так что вот ответ: EASTL теперь доступен в github: https://github.com/paulhodge/EASTL
У Ultimate ++ есть свой собственный набор контейнеров - не уверен, что вы можете использовать их отдельно от остальной библиотеки: http://www.ultimatepp.org/
Проверка структуры данных и алгоритмов с объектно-ориентированными шаблонами проектирования в С++ Бруно Прейсс http://www.brpreiss.com/
Qt перепрофилировал большинство материалов стандартной библиотеки С++ с различными интерфейсами. Это выглядит неплохо, но это может быть дорогостоящим для коммерчески лицензированной версии.
Изменить: Qt с тех пор был выпущен под LGPL, который обычно позволяет использовать его в коммерческом продукте без использования коммерческой версии ( который также существует).
Контейнеры STL не должны запускаться "очень медленно" в отладке или в другом месте. Возможно, вы злоупотребляете ими. Вы не работаете против чего-то вроде ElectricFence или Valgrind в отладке? Они замедляют все, что делает много распределений.
Все контейнеры могут использовать пользовательские распределители, которые некоторые используют для повышения производительности, но мне никогда не приходилось использовать их самостоятельно.
Как насчет ACE library? Это объектно-ориентированная среда с открытым исходным кодом для параллельного программного обеспечения связи, но в ней также есть несколько классов контейнеров.