Я использую довольно много STL в критическом по производительности C++-коде под окнами. Одним из возможных «дешевых» способов получить дополнительную производительность было бы перейти на более быструю библиотеку STL.Переключение с Microsoft STL на STLport
В соответствии с этим post STLport быстрее и использует меньше памяти, однако ему несколько лет.
Кто-нибудь сделал это изменение недавно и каковы были ваши результаты?
Я не сравнивал производительность STLPort с MSCVC, но я был бы удивлен, если бы была разница значительная разница. (Конечно, в режиме выпуска - отладочные сборки, скорее всего, будут совсем другими). К сожалению, ссылка, которую вы предоставили, и любое другое сравнение, которое я видел, слишком легки в деталях, чтобы быть полезными.
Прежде чем даже рассмотреть вопрос об изменении стандартных поставщиков библиотек, я рекомендую вам тщательно профилировать свой код, чтобы определить, где узкие места. Это стандартный совет; всегда профайл, прежде чем пытаться улучшить производительность!
Даже если профилирование выявляет проблемы с производительностью в стандартных библиотечных контейнерах или алгоритмах, я бы предложил сначала проанализировать , как вы их используете. Алгоритмические улучшения и соответствующий выбор контейнеров, особенно учитывая затраты Big-O, - это , а гораздо больше, что может привести к большей отдаче от производительности.
Я не пробовал, но насколько я знаю, серьезных изменений в реализации STL Microsoft не произошло. (В VS2008-компиляторе за 2005 год также нет огромных новых оптимизаций). Так что если STLPort был быстрее, это, вероятно, так и есть.
Но это просто предположение. :) Обязательно сообщите о результатах, если вы попробуете его.
Одним из преимуществ stlport является то, что он с открытым исходным кодом.
верно, но не имеет отношения к вопросу – 0xC0DEFACE
Интересно, как вы могли бы даже создать реализацию – jalf
STL с закрытым исходным кодом, как легко, как только не добавляя лицензии с открытым исходным кодом для заголовочных файлов. Помните, что открытый источник относится к лицензированию, а не к тому, можете ли вы читать источник или нет ... – Benj
В проекте, над которым я работал, это довольно интенсивное использование stl, переход на STLport привел к тому, что все было сделано за половину времени, затраченного на реализацию STL в Microsoft. Это не доказательство, но это хороший признак производительности, я думаю. Я считаю, что отчасти это связано с усовершенствованной системой управления памятью STLport.
Я помню некоторые предупреждения, когда делал это изменение, но ничего, что не могло быть быстро обработано. В качестве недостатка я бы добавил, что отладка с помощью STLport менее легка с отладчиком Visual Studio, чем с Microsoft STL (обновление: похоже, есть способ объяснить отладчику, как обрабатывать контейнеры STLport, спасибо Jalf!).
Последняя версия восходит к октябрю 2008 года, поэтому на ней все еще работают люди. См. here для его загрузки.
Об отладке, разве это не вопрос настройки правильных визуализаторов для отладчика? http://stlport.svn.sourceforge.net/viewvc/stlport/trunk/STLport/etc/autoexp.dat?revision=HEAD – jalf
Ницца! Я попробую! –
Можете ли вы подсчитать сумму своего «половинного времени»? Правильно ли я предполагаю, что вы использовали сборку релизов? Что вы делали? – MattyT
Если вы используете STLPort вы войдете в мир, где каждый STL-библиотека на основе третьей стороны вы используете должны быть перекомпилировать с STLPort, а также, чтобы избежать проблем ...
STLPort действительно имеет другую стратегию памяти , но если это ваше узкое место, то ваш путь усиления производительности меняет распределитель (например, переключается на Hoard), не изменяя STL.
stlport можно настроить на использоваться совместно с stl. Это просто означает, что вы должны быть более преднамеренными в своем использовании, а не просто заменой. – 0xC0DEFACE
Перед тем, как сделать коммутатор, обязательно проверьте, что MS (на самом деле, Dinkumware) библиотека выключена checked iterators.По какой-то странной причине они включаются по умолчанию даже в сборках релизов, и это имеет большое значение, когда дело доходит до производительности.
Очень хороший момент, это имеет серьезные отличия. Я сам их отключил, но это может быть причиной ускорения в блоге, о котором я упоминал в своем сообщении. – Laserallan
В последнее время мы сделали противоположную задачу. Наше приложение является кросс-платформенной серверной программой на C++ и построено на 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 используются, поскольку библиотека STL по умолчанию gcc использует COW-строки. В нашем приложении мы выполняем множество строковых присвоений, и в результате строк COW мы получаем худшую производительность. Поэтому мы по-прежнему используем STLPort на HP-UX с gcc.
Я сделал прямо противоположный год назад, и вот почему:
Пришел здесь с той же проблемой. Фактически, учитывая, что в VS2010 у вас нет карт хеш-наборов и всего остального, введенного в 2005-2007 гг. Из TR1, разница может быть разницей в O (1) и O (N) .... – ntg