Применение template и STLport дало +~25% реальной производительности сис-мы в целом, при потере 98КБ. Но что такое 100 КБ при сегодняшних требованиях.
Причем код стал красивее, читабельнее и конечно на пару 1000 строк меньше.

Если раньше прога успевала передать ~43000 пакетов за 10 сек, то после реализации диспетчера, на базе template + STLport, равно >54000 пакетов.

З.Ы.: Что за пакеты и система объяснять не буду. Долго

З.Ы.Ы.: не изобретайте велосипедов юзайте то, что сделали до и за вас

Истину говоришь (: Я тоже сначала для каждой проги все свое писать стремился, а потом понял, что все уже написано до нас. STL-ы, boost-ы всякие... Полностью согласен.

А я вот не доверяю им(STLport, boost). Может из-за того, что не умею пользоваться. ЗЫ а вот шаблоны(так как - это стандарт ООП+С++) - это действительно полезная вешь!
Для программ "стремлюсь, буду и есть" писать только своё. Если ПО на продажу, то тем более надо подходить серьезно.
Прирост производительности, чаще всего в 98% можно получить за счет грамотно составленного алгоритма.

Цитата

А я вот не доверяю им(STLport, boost). Может из-за того, что не умею пользоваться. ЗЫ а вот шаблоны(так как - это стандарт ООП+С++)

STL тоже в стандарт входит.
А что косается того что реализован он разными производителями, то и компиляторы разные люди пишут.

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

Цитата

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

STL и шаблоны - вещь - пишут люди, которые реально и грамотно используют template и STL, что ускоряет разработку и повышает производительность системы.
STL и шаблоны - зло - пишут люди, которые не умеют грамотно и правильно использовать template и STL. И которым сказали лет 10 назад, что template "жрет" память.
STL и шаблоны - тема - пишут люди, которые сами толком не умею еще разрабатывать код на основе template, но считают, что это круто, когда шаблоны.
STL использовать не следует, а следует писать при помощи тех же шаблонов свои контейнеры - бред! Тогда уже сразу и компилятор пускай свой напишут.

Добавлено @ 09:49

Цитата

Прирост производительности, чаще всего в 98% можно получить за счет грамотно составленного алгоритма.

Программа - это набор "кучи" алгоритмов. И поэтому составить все алгоритмы грамотно и оптимизировано - потратить в 10 раз больше времени на разработку. Да и все равно, что-то, где-то упустишь.
Правило оптимизации:
1. Никогда не оптимизируй
2. Если все же решили оптимизировать кусок кода - смотри правило №1

WAAGH!!!, через 2  года я осознал, что ошибался 

Поделись в чем же именно, что бы не повторять чужих ошибок.

Читай первый пост   

оппа, ну и темка была.

Да, да, я согласен. Потратив в 10 раз больше времени на пересоставление и отладку алгоритмы, можно добиться прироста 10% производительности - обобщенно.

И в 99% процентах случаев оно того не стоит 

<уклоняясь от уже летящих помидоров>
Не то, чтобы согласен, но поддерживаю  Почему?

STL - это в первую очередь идеи как таковые, а во вторых чёткая специализация контейнера в STL-style. Скажем, даже банальные мэпы и множества на базе хеш-таблиц включены были очень недавно. Если мне нужен свой котейнер (специфический контейнер - алгоритмов и подходов к хранению коллекций данных масса), почему бы его не сделать? И ещё, все знают, что Qt содержит свой набор контенеров (естественно, stl-совместимых, иначе бы в топку их). Вначале я их не использовал. Из принципа  Затем, вообщем то перешёл на них (естественно, если Qt используется в проекте в принципе,  но это верно в большинстве случаев для меня). Почему?

1. Implicit sharing. Кто бы что ни говорил, мне нравиться  В частности, прямой возврат из функции контейера без большого падения перформанса, да и вообще вещь удобная ИМХО.
2. В Qt часто используются кутешные контейнеры (наиболее раздражающее исключение - получение чайлд-ноудов DOM-узла, этот список - отдельный класс, не stl-совместимый, жутко неудобно :( ). Скакать с одних контейнеров на другие не вижу смысла...
3. Более удобно АПИ. В частности, тот факт, что в QMap/QHash value_type есть именно тип значения, а не std::pair (кутешные итераторы для этих классов кроме разыменования имеют методы key(), value()). Для меня сие удобно.

А я наоборот осознал полезность изобретения велосипедов. Причём как по соображениям самообучения, так и по соображениям эффективности. Пока что некоторые вещи в STL реализуются неэффективно.

И понеслась.........
В общем начинает разгораться нешуточный спор, место которому в религиозных войнах!
Может быть закрыть тему пока не поздно?
А то новички (я например) как всегда обалдеют от потока информации   

не, ну это да.

То есть написал велосипед, сравнил со стандартным решением, выкинул.
Через время написал велосипед, сравнил по скорости, остался удовлетворен, сравнил интерфейс, выкинул.
Еще через время переписал велосипед, нашёл компромисс между скоростью и интерфейсом, сравнил оба параметра со стандартными, осознал то, что стандартную реализацию всё-таки не дураки писали (как правило ;)), дальше

либо 1) своё компромиссное решение оказалось не лучше. Оставил себе на память 
либо 2) добился прироста. Опубликовал, начал развивать
                  2а) потом забил
                  2б) развиваешь дальше, вписываешь своё имя в историю ПО

Была система в 250 kb чистого кода. Писалась на C++ но большей частью это был C, с велосипедами скрывающими в себе массивы char'ов и прочие опасные вещи. На этапе интегрирования(различных подсистем) и тестирования выявилась ошибка работы с памятью, локализировать которую сразу не смог. Разбираться в 250 kb кода, написанного большей частью ночью не очень хотелось. Выбросил полностью всю систему, оставил только идею подсистем, в итоге применение шаблонов, контейнеров, макросов(хоть и не по теме, но всё же) привело к тому, что с памятью вообще сам не работаю, всё делают вещи из стандартной библиотеки, код ужался до 85 kb кода и стал более читабельным.
Хотя некоторые вещи, такие как суперпозиция шаблонов и наследования не всегда понятны сразу при чтении программы.