Переключатель от STL Microsofts до STLport
(1/3) означает целочисленное деление, поэтому вы не можете получить десятичное значение из этого деления. Для решения этой проблемы используйте:
public static void main(String[] args) {
double g = 1.0 / 3;
System.out.printf("%.2f", g);
}
7 ответов
Я не сравнил производительность STLPort к MSCVC, но я был бы удивлен, было ли значительно различие. (В режиме выпуска, конечно - сборки отладки, вероятно, будут очень отличаться.), К сожалению, ссылка Вы обеспечили - и любое другое сравнение, которое я видел - слишком легко в деталях, чтобы быть полезным.
Перед ровным рассмотрением изменяющихся типичных поставщиков библиотеки я рекомендую в большой степени представить код для определения, где узкие места. Это - стандартный совет; всегда профиль прежде, чем делать попытку любых повышений производительности!
, Даже если бы профилирование действительно показывает проблемы производительности в стандартных контейнерах библиотеки или алгоритмах, которые я предложил бы, Вы сначала анализируете , как Вы используете их . Алгоритмические улучшения и соответствующий контейнерный выбор, особенно рассматривая Большие-O затраты, намного больше , вероятно, для обеспечения больших возвратов в производительности.
Перед переключением, убедиться протестировать MS (на самом деле, Dinkumware) библиотека с проверенные итераторы выключенный. По некоторой странной причине они включены по умолчанию даже в сборках конечных версий, и это имеет большое значение когда дело доходит до производительности.
В проекте я работал над этим, делает довольно интенсивное использование stl, переключение на STLport привело к добиванию цели в половину времени, которое потребовалось с реализацией STL Microsoft. Это не доказательство, но это - хороший знак производительности, я предполагаю. Я полагаю, что это происходит частично из-за усовершенствованной системы управления памятью STLPORT.
я действительно не забываю получать некоторые предупреждения при внесении этого изменения, но ничто, что не могло работаться вокруг быстро. Как недостаток, я добавил бы, что отладка с STLport менее легка с отладчиком Visual Studio, чем с STL Microsoft (Обновление: кажется, что существует способ объяснить отладчику, как обработать контейнеры STLport, Jalf спасибо!).
последняя версия возвращается до октября 2008, таким образом, существуют все еще люди, работающие над нею. См. здесь для загрузки его.
При использовании STLPort, Вы введете мир, где каждая основанная на STL сторонняя библиотека, которой Вы пользуетесь, должна будет быть перекомпилирована с STLPort также для предотвращения проблем...
STLPort действительно имеет другую стратегию памяти, но если это - Ваше узкое место тогда, Ваш путь увеличения производительности изменяет средство выделения (переключающийся для Рекламного щита, например), не изменяя STL.
Я не попробовал его, но насколько я знаю, не было никаких существенных изменений к реализации STL Microsoft. (Нет никакой огромной новой оптимизации в компиляторе VS2008 за 2005 ни одного), Поэтому, если STLPort был быстрее тогда, он, вероятно, все еще имеет место.
, Но это - просто предположение.:) Убедиться сообщить о результатах, если Вы испытываете его.
Одно преимущество stlport - то, что это - открытый исходный код.
Недавно мы выполнили противоположную задачу. Наше приложение представляет собой кроссплатформенную серверную программу 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.