Използвам доста STL в критичен за производителността C++ код под Windows. Един възможен "евтин" начин да получите допълнителна производителност би бил да преминете към по-бърза STL библиотека.
Според тази публикация STLport е по-бърз и използва по-малко памет, но е на няколко години.
Някой направил ли е тази промяна наскоро и какви бяха вашите резултати?
Не съм сравнявал производителността на STLPort с MSCVC, но бих се изненадал, ако има значителна разлика. (Разбира се, в режим на освобождаване - компилациите за отстраняване на грешки вероятно ще бъдат доста различни.) За съжаление връзката, която предоставихте - и всяко друго сравнение, което съм виждал - е твърде малко по отношение на подробностите, за да бъде полезно.
Преди дори да обмислите смяна на доставчици на стандартни библиотеки, препоръчвам ви да профилирате сериозно своя код, за да определите къде са тесните места. Това е стандартен съвет; винаги профилирайте, преди да опитате подобрения на производителността!
Дори ако профилирането разкрие проблеми с производителността в стандартни библиотечни контейнери или алгоритми, бих ви предложил първо да анализирате как ги използвате. Алгоритмичните подобрения и подходящата селекция на контейнери, особено като се имат предвид големи разходи, е много по-вероятно да донесат по-голяма възвръщаемост на производителността.
Преди да направите превключването, не забравяйте да тествате MS (всъщност Dinkumware) библиотеката с проверени итератори е изключено. По някаква странна причина те са включени по подразбиране дори в версиите на версията и това прави голяма разлика, когато става въпрос за производителност.
Наскоро направихме обратната задача. Нашето приложение е 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 и да използваме библиотеката по подразбиране VS 2008 STL.
При 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.
В проект, върху който работих, който използва доста интензивно stl, преминаването към STLport доведе до свършване на нещата за половината от времето, необходимо за изпълнението на STL на Microsoft. Не е доказателство, но е добър знак за ефективност, предполагам. Вярвам, че отчасти се дължи на усъвършенстваната система за управление на паметта на STLport.
Спомням си, че получих някои предупреждения, когато направих тази промяна, но нищо, което не можеше да бъде заобиколено бързо. Като недостатък бих добавил, че отстраняването на грешки с STLport е по-малко лесно с дебъгера на Visual Studio, отколкото с STL на Microsoft (Актуализация: изглежда има начин да се обясни на дебъгера как да се справят с контейнерите на STLport, благодаря Jalf!).
Последната версия е от октомври 2008 г., така че все още има хора, които работят по нея. Вижте тук за изтеглянето му.
Аз направих точно обратното преди година и ето защо:
Ако използвате STLPort, ще влезете в свят, в който всяка STL-базирана библиотека на трета страна, която използвате, ще трябва да бъде прекомпилирана със STLPort, за да се избегнат проблеми...
STLPort има различна стратегия за памет, но ако това е вашето тясно място, тогава вашият път за увеличаване на производителността е промяна на разпределителя (превключване към Hoard например), а не промяна на STL.
Не съм го пробвал, но доколкото знам, няма големи промени в реализацията на STL на Microsoft. (В компилатора VS2008 също няма огромни нови оптимизации през 2005 г.) Така че, ако STLPort беше по-бърз тогава, вероятно все още е така.
Но това са само спекулации. :) Не забравяйте да докладвате за резултатите, ако го изпробвате.
Едно предимство на stlport е, че е с отворен код.
