STL Альтернатива

Question

Я действительно ненавижу использовать контейнеры STL, потому что они заставляют отладочную версию моего кода работать очень медленно. Что другие люди используют вместо STL, который имеет разумную производительность для отладочных сборок?

Я программист, и это было проблемой для многих проектов, над которыми я работал. Довольно сложно получить 60 кадров в секунду, когда вы используете контейнер STL для всего.

Я использую MSVC для большей части моей работы.

Answer 1

EASTL возможен, но все еще не совершенен. Пол Педриана из Electronic Arts провел исследование различных реализаций STL в отношении производительности в игровых приложениях, краткое изложение которых можно найти здесь: http://www.open -std.org / ОТК1 / SC22 / wg21 / документы / документы / 2007 / n2271.html

Некоторые из этих корректировок в настоящее время рассматриваются для включения в стандарт C ++.

И обратите внимание, даже EASTL не оптимизируется для неоптимизированного случая. У меня был файл Excel с некоторыми временами, но я думаю, что потерял его, но для доступа это было что-то вроде:

       debug   release
STL      100        10
EASTL     10         3
array[i]   3         1

Самый большой успех, который я имел, катал мои собственные контейнеры. Вы можете снизить их до производительности, близкой к массиву [x].

Answer 2

Мой опыт показывает, что хорошо отлаженный код STL работает медленно в отладочных сборках, потому что оптимизатор выключен. Контейнеры STL посылают много вызовов конструкторам и оператору =, который (если они имеют малый вес) вставляется / удаляется в сборках релиза.

Кроме того, в Visual C ++ 2005 и более поздних версиях включена проверка STL в сборках выпуска и отладки. Это огромный скачок производительности для STL-тяжелого программного обеспечения. Его можно отключить, определив _SECURE_SCL = 0 для всех ваших модулей компиляции. Обратите внимание, что наличие разных состояний _SECURE_SCL в разных блоках компиляции почти наверняка приведет к катастрофе.

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

Answer 3

Если у вас работают визуальные студии, вы можете рассмотреть следующие вопросы:

#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0

Это только для итераторов, какой тип операций STL вы выполняете? Возможно, вы захотите взглянуть на оптимизацию операций с памятью; то есть, используя resize () для вставки нескольких элементов одновременно вместо использования pop / push для вставки элементов по одному.

Answer 4

Для больших приложений, критичных к производительности, создание собственных контейнеров, специально адаптированных к вашим потребностям, может стоить затрат времени.

Я говорю о реальной разработке игр здесь.

Answer 5

Если вы используете Visual C ++, вы должны взглянуть на это:

http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/

и ссылки с этой страницы, которые покрывают различные расходы и опции всей проверки режима отладки, которую выполняет MS / Dinkware STL.

Если вы собираетесь задать такой зависимый от платформы вопрос, было бы неплохо упомянуть и вашу платформу ...

Answer 6

Держу пари, что ваш STL использует проверенную реализацию для отладки. Это, вероятно, хорошая вещь, поскольку она будет перехватывать итераторы и тому подобное. Если для вас это большая проблема, возможно, есть переключатель компилятора, который отключит его. Проверьте свои документы.

Answer 7

Извините, я не могу оставить комментарий, поэтому вот ответ: EASTL теперь доступен на github: https://github.com/paulhodge/EASTL

Answer 8

MSVC использует очень тяжелую реализацию проверенных итераторов в отладочных сборках, о которых другие уже говорили, поэтому я не буду повторять это (но начну там)

Еще одна вещь, которая может вас заинтересовать, заключается в том, что ваши «отладочная сборка» и «сборка выпуска», вероятно, включают в себя изменение (как минимум) 4 параметров, которые имеют слабую связь.

1. Создание файла .pdb (cl / Zi и link / DEBUG), который позволяет проводить символьную отладку. Вы можете добавить / OPT: ref к параметрам компоновщика; компоновщик удаляет функции, на которые нет ссылок, когда не создает файл .pdb, но в режиме / DEBUG он сохраняет их все (так как символы отладки ссылаются на них), если вы не добавите это точно.
2. Использование отладочной версии библиотеки времени выполнения C (возможно, MSVCR * D.dll, но это зависит от используемой среды выполнения). Это сводится к / MT или / MTd (или что-то еще, если не использовать среду выполнения DLL)
3. Отключение оптимизации компилятора (/ Od)
4. установка препроцессора #defines DEBUG или NDEBUG

Они могут переключаться независимо. Первый ничего не стоит в производительности во время выполнения, хотя он добавляет размер. Вторая делает ряд функций более дорогостоящими, но оказывает огромное влияние на malloc и free; версии отладочной среды стараются «отравить» память, к которой они обращаются, значениями, чтобы очистить неинициализированные ошибки данных. Я полагаю, что с реализациями MSVCP * STL это также устраняет все пулы распределения, которые обычно выполняются, так что утечки показывают именно тот блок, который вы думаете, а не какой-то больший кусок памяти, который он перераспределяет; это означает, что он делает больше вызовов malloc поверх них намного медленнее. Третий; хорошо, что каждый делает много вещей ( этот вопрос имеет хорошее обсуждение предмета). К сожалению, это необходимо, если вы хотите, чтобы пошаговый режим работал плавно. Четвертый затрагивает множество библиотек различными способами, но наиболее примечателен, он компилируется или удаляет assert () и друзей.

Так что вы можете подумать о том, чтобы сделать сборку с меньшей комбинацией этих вариантов. Я часто использую сборки, которые используют символы (/ Zi и link / DEBUG) и утверждения (/ DDEBUG), но все еще оптимизированы (/ O1 или / O2 или любые другие флаги, которые вы используете), но с указателями кадров стека, сохраненными для очистить трассировки (/ Oy-) и использовать обычную библиотеку времени выполнения (/ MT). Это работает близко к моей сборке релиза и является полуотладимым (обратные трассировки в порядке, пошаговое выполнение немного странно на уровне исходного кода; уровень сборки, конечно, работает нормально). Вы можете иметь сколько угодно конфигураций; просто клонируйте свой первый релиз и включите те части отладки, которые кажутся полезными.

Answer 9

Выезд EASTL .

Answer 10

Qt переопределил большинство стандартных библиотек c ++ с различными интерфейсами. Это выглядит довольно хорошо, но это может быть дорого для коммерческой версии.

Редактировать: Qt с тех пор выпущен под LGPL , что обычно позволяет использовать его в коммерческом продукте без поддержки коммерческой версии (которая также существует).