Какая реализация STL с наименьшим объемом памяти?

Question

Я работаю над очень крупной вычислительной библиотекой, которая интенсивно использует STL. Библиотека создается с использованием MSVC2003 и использует реализацию STL. Я ищу альтернативную реализацию STL, которая помогла бы библиотеке снизить требования к памяти и повысить производительность.

На данный момент невозможно перейти на более новую версию MSVC.

Я хотел бы получить отзывы об использовании в реальном мире, не основанные на тестах, если это возможно.

РЕДАКТИРОВАТЬ: чтобы сделать это немного яснее, например, некоторые реализации STL (например, STLSoft) предлагают конкретные оптимизации для конкатенации строк; это может звучать незначительно, но может привести к значительным улучшениям. STLPort - еще один хороший пример, где они четко заявляют о своей цели: иметь самую быструю реализацию STL, есть stdlib ++ и т. Д. ... все это может быть хорошим кандидатом, но у меня нет времени проверять их все, мне нужна помощь сообщества на этом.

Answer 1

STLPort . Не измерял различия в использовании памяти, но он определенно быстрее (да, в реальном мире).

Answer 2

Я подвергаю сомнению вашу основную предпосылку, что вы не можете перейти на более новую версию MSVC.

Я не думаю, что вы получите меньше памяти и увеличите производительность "бесплатно", загрузив новый STL. Или, по крайней мере, если бы вы это сделали, вам, вероятно, пришлось бы делать столько исправлений кода, как если бы вы просто обновляли MSVC до последней версии.

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

Единственное, что я могу предложить вам в соответствии с тем, что вы говорите, вы ищете, это попробовать компилятор Intel, который у меня был как хороший (производительность!), Так и плохой (странный, иногда !) опыт работы с.

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

Answer 3

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

Answer 4

Большая часть зависит от того, о каком контейнере вы говорите и как вы его используете. Вектор обычно имеет наименьшую площадь, за исключением того момента, когда вы добавляете элемент, который превышает текущую емкость вектора. В этот момент он выделит что-то вроде 1,5-кратной текущей емкости векторов, переместит элементы (или в худшем случае создаст новую копию, которая также выделяет память), а когда это будет сделано, удалит старые внутренние векторы, если вы знаете, как много элементов, которые он собирается держать впереди, вектор с использованием резерва - ваша лучшая ставка.

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

На MSVC обязательно #define _SECURE_SCL = 0 Это устраняет много накладных расходов, используемых для проверок безопасного программирования (например, переполнения буфера и т. Д.)

Безусловно, наиболее эффективные для памяти контейнеры являются наддувами / навязчивыми. Они имеют очень малые следы, поскольку используют память того, что в них содержится. Таким образом, в стремлении перейти к куче небольшого куска памяти для связанного списка или узла дерева rb, указатели узлов являются частью самого объекта. Тогда «контейнер» - это всего лишь один необработанный набор из нескольких указателей для создания корневого узла. Я использовал его несколько раз, чтобы избавиться от площади и затрат на распределение.

Answer 5

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

Answer 6

Если производительность так важна для вашего приложения, и STL вплетен в нее, можно ли найти реализацию с открытым исходным кодом (например, STL-Port , как уже упоминалось) и разветвить ее для себя , как улучшить производительность при необходимости?

С одной стороны, я вижу, как это становится скользким уклоном, когда вы вносите нестандартные модификации в свой форк библиотеки STL, создавая тем самым проблемы. Однако важность производительности для вашего приложения может перевесить риск этого.

Answer 7

Большинство реализаций STL, включая MSVC2003, являются хорошо реализованными универсальными библиотеками. Таким образом, вы не увидите значительного улучшения производительности от одной реализации к другой.

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

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