Я использую довольно много STL в критическом для производительности С++-коде под окнами. Одним из возможных "дешевых" способов получения дополнительной производительности было бы перейти на более быструю библиотеку STL.
В соответствии с этим post STLport быстрее и использует меньше памяти, однако это несколько лет.
Кто-нибудь сделал это изменение недавно и каковы были ваши результаты?
Я не сравнивал производительность STLPort с MSCVC, но я был бы удивлен, если бы была значительная разница. (Конечно, в режиме выпуска - отладочные сборки, скорее всего, будут совсем другими). К сожалению, ссылка, которую вы предоставили, и любое другое сравнение, которое я видел, слишком легкое, чтобы детали были полезными.
Прежде чем рассматривать возможность изменения стандартных поставщиков библиотек, я рекомендую вам тщательно профилировать свой код, чтобы определить, где узкие места. Это стандартный совет; всегда профиль, прежде чем пытаться улучшить производительность!
Даже если профилирование выявляет проблемы с производительностью в стандартных библиотечных контейнерах или алгоритмах, я бы предложил сначала проанализировать, как вы их используете. Алгоритмические усовершенствования и соответствующий выбор контейнеров, особенно учитывая затраты на Big-O, гораздо более эффективны для повышения производительности.
Прежде чем приступить к работе коммутатора, обязательно проверьте, отключена ли библиотека MS (на самом деле, Dinkumware) с проверены итераторы. По какой-то странной причине они включаются по умолчанию даже в сборках релизов, и это имеет большое значение, когда дело доходит до производительности.
Недавно мы сделали противоположную задачу. Наше приложение является кросс-платформенной серверной программой на С++ и построено на Windows с VS 2008 (x86) и на HP-UX ia64 и Linux с gcc 4.3. На каждой платформе мы использовали STLport 5.1.7 в качестве библиотеки STL и Boost 1.38.
Чтобы сравнить производительность некоторое время назад, мы также создали наше приложение без STLport, и после этого мы измерили производительность.
После этого на Windows производительность стала немного лучше. Поэтому мы решили прекратить использование STLport с VS 2008 и использовать стандартную библиотеку STL по умолчанию VS 2008.
В HP-UX ia64 было снижение производительности на 20%. Caliper (профайлер HP-UX) показал, что назначение строк занимает больше времени. И внутри назначения строк в стандартной библиотеке gcc STL были вызовы pthread_mutex_unock. Насколько я знаю, pthread_mutex_lock/pthread_mutex_unlock используются, поскольку библиотека gcc STL по умолчанию использует COW-строки. В нашем приложении мы выполняем множество строковых присвоений, и в результате строк COW мы получаем худшую производительность. Поэтому мы по-прежнему используем STLPort на HP-UX с gcc.
В проекте, над которым я работал, он довольно сильно использует stl, переход на STLport привел к тому, что все было сделано за половину времени, затраченного на внедрение Microsoft STL. Это не доказательство, но это хороший признак производительности, я думаю. Я считаю, что отчасти это связано с расширенной системой управления памятью STLport.
Я помню, чтобы получать некоторые предупреждения при выполнении этого изменения, но ничего, что не могло быть быстро обработано. В качестве недостатка я бы добавил, что отладка с помощью STLport менее легка с отладчиком Visual Studio, чем с Microsoft STL (обновление: похоже, есть способ объяснить отладчику, как обрабатывать контейнеры STLport, спасибо Jalf!).
Последняя версия восходит к октябрю 2008 года, поэтому на ней все еще работают люди. См. здесь для его загрузки.
Я сделал совершенно противоположное год назад, и вот почему:
Если вы используете STLPort, вы войдете в мир, в котором каждая используемая вами сторонняя библиотека на основе STL должна быть перекомпилирована с помощью STLPort, чтобы избежать проблем...
У STLPort есть другая стратегия памяти, но если это ваше узкое место, то ваш путь усиления производительности меняет распределитель (например, переключается на Hoard), не изменяя STL.
Я не пробовал, но, насколько мне известно, серьезных изменений в реализации Microsoft STL не произошло. (В VS2008-компиляторе за 2005 год также нет огромных новых оптимизаций). Так что если STLPort был быстрее, возможно, это все равно.
Но это просто предположение.:) Обязательно сообщите о результатах, если вы попробуете его.
Одно из преимуществ stlport заключается в том, что он с открытым исходным кодом.