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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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