Приветствую!
Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации.
Были.

S>Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Причина возрастания производительности — проведенная оптимизация, тут все просто. А вот насчет причин... Случаев было много и разных. Перечислять все?

Приветствую, Bell, вы писали:

B> Причина возрастания производительности — проведенная оптимизация, тут все просто. А вот насчет причин... Случаев было много и разных. Перечислять все?

Ну хотябы самые яркие

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Много, совершенно разных.

Из впечатлившего — вставка большой кучи узлов в виндовый Treeview тормозит с TVI_LAST, но примелемо работает с TVI_FIRST. Там, видать, односвязный список.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Bell, вы писали:

B>> Причина возрастания производительности — проведенная оптимизация, тут все просто. А вот насчет причин... Случаев было много и разных. Перечислять все?

S>Ну хотябы самые яркие
Замена пузырьковой сортировки на std::sort в одном алшгоритме — улучшение примерно в 7 раз.
Кэширование результатов — много случаев с различным эффектом.
Банальный перенос реализации некоторых функций из .cpp в .h с модификатором inline
Полное переосмысление и переписывание некоторых кусков.

...

А вообще сложно перечислять — каждый случай по-своему уникален Перечислять все лень, а пытаться писать обо всех сразу — получаются общие слова...

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

1. Совсем недавно, пару недель назад. Во время тестирование очередного релиза, заметили падение производительности примерно в 3 раза по сравнению с предыдущей версией. Начали разбираться, обнаружили добавление в некоторый маленький классик нового поля, указателя, который создавался через new (зачем так было сделано, осталось тайной). Объектов такого класса создавалось очень много, отсюда и тормоза. Заменили на значение, все вернулось.
2. Заменили qt-шный xml парсер на xerces, ускорилась загрузка проги (правда насколько точно не считали)
3. Заменили boost::pool'ом свой велосипед, boost'овский работает чуть медленне.
4. Заменили свой stl-совместимый аллокатор стандартным, построение некоего дерева стало работать медленнее.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

жил-был огромный класс, который кушал много памяти и требовал много времени на копирование-конструирование, жил он в коде для embedded device'а, имел много экземпляров и печалил несказанно он многия разработчиков и проектных менеджеров.
А потом его переписали с помощью идиомы COW.
И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Самый заметный прирост производительности будет при оптимизации алгоритмов — это очевидно, об этом не писал и не говорил только ленивый. Замена O(n^2) хотя бы на O(n) уже даст тебе на порядок более быстрый алгоритм

Из того, что относительно недавно было у нас

Было. Страница, открывающаяся до 3 минут:

result_set = выборка_из_базы_данных
for result in result_set
    additional_result = еще_один_запрос
    вывод

Стало. Страница, открывающаяся за 20 секунд

result_set = выборка_из_базы_данных_всех_данных_сразу
for result in result_set
   вывод

Иногда компьютеру надо подсказать/помочь с оптимизацией алгоритма.

Например. Относительно некрупный SQL-запрос, с несколькими джойнами. Работа — около 20-30 секунд. Проверка плана запроса показала, что в одной из таблиц идет полное сканирование таблицы, 90% времени запроса проводилось в ней. Проверка таблицы показала отсутствие в таблице необходимых индексов и ключей. После добавления запрос стал работать 2-5 секунд.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Был у нас забавный случай. QListView, заполнялся строчками. Для каждой строчки создавалась картинка QPixmap ( из файла загружалась ). Это было медленно и, скорее всего, много памяти отъедало. Потом это нашли и поменяли на один QPixmap, который устанавливался на каждую строчку. Скорость прокрутки ListView возросла даже на глаз.

Из того, что сейчас помню — сортировка списков списков. В первоначальном варианте выполнялось глубокое копирование, когда заметили — заменили на swap голов.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Вспомнить сложно. И ещё сложнее описать.
Самый яркий случай — ускорил одну функцию примерно в 5 тысяч раз.
Эта функция вызывалась в меню и в результате на больших моделях программа недопустимо тормозила — более 5 секунд на открывание контекстного меню.
Причина — плохой алгоритм, проверялся сам элемент и все его дочерние элементы на наличие некоторого стереотипа.
Переписал по другому — находил все экземпляры этого стереотипа и кому он принадлежит, а далее проверял, что он не принадлежат искомому элементу.

Здравствуйте, Sheridan, Вы писали:

B>> Причина возрастания производительности — проведенная оптимизация, тут все просто. А вот насчет причин... Случаев было много и разных. Перечислять все?
S>Ну хотябы самые яркие

Было такое...
Небольшой классик в котором хранятся числа а иногда, в дополнение к ним, и строки.
Первоначальный вариант:

typedef std::vector <std::string> multistring;
struct value
{
    int a;
    int b;
    multistring s;
};

Работало достаточно медленно. Объектов таких создаётся и разрушается огромное количество, конструкор/деструктор даже такого простого объекта как std::vector на общем фоне давали значительную просадку по производительности. Немного переделали. Завели указатель и, когда нужно, динамически создавали/уничтожали список строк.

struct value
{
    int a;
    int b;
    multistring* p;
};

Получилось ещё хуже. Несмотря на то, что строки использовались достаточно редко, накладные расходы на выделение/освобождение памяти под сам вектор съели бонусы от поредевших вызовов конструкторов/деструкторов. После этого ещё немного переделали, совместив оба подхода. Так и оставили — по производительности устраивает:

struct value
{
    int a;
    int b;
    multistring* p;
    char x [sizeof (multistring)];
};
// и когда нужно:
p = new (x) multistring;
p -> ~multistring ();

В дальнейшем неоднократно использовали этот приём в аналогичных ситуациях.

MQ>p = new (x) multistring;
MQ>p -> ~multistring ();

А менеджер динамической памяти поменять не пробовали?

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

наиболее яркие примеры из моей приктики:

* в неком китайском коде http сервера был форк 1-2 thread'ов (одного или иногда двух! -- такая вот там замысловатая логика была) для обработки приходящего запроса... переписано на pool worker'ов и fifo с запросами -- со 120 запросов в секунду подняли до 6000 (ядро сервера было выкинуто нафиг, бизнес логику оставили оригинальной (такоже уродской как и был сервер)).

* еще один яркий случай описан здесь

Автор: zaufi
Дата: 01.12.06

* в далекие (уже) времена когда мы переходили на только начинающий стабилизироваться gcc 3.0 пересобрав на наш проект к ключиками для амд атлона и сравнив их с собранным под пень4 получили 20-30% увеличение производительности (погуглив оказалось что амдшные парни плотно работали с гцц тимом над правильным шедулером) -- потом мы стали покупать больше компов с амд )

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Да уж много всякого было. Если не считать глупых ошибок, например, приводящих к многократным вычислениям того, что по задумке должно было вычисляться один раз в стартапе, *существенного* улучшение производительности обычно сводилось к усовершенствованию алгоритмов. Весьма интересной в этом плане была задача построения физической модели мира для 3D игрушек. Тут был ряд усовершенствований как в области Collision detection, так и в самой модели обсчета взаимодействий — это и пространственная оптимизация и разделение тел на подвижные и неподвижные, и оптимизация просчета статики при множественных контактах тел, своевременное "замораживание" подвижных тел и тому подобное.

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

Автор(ы): Максим Шеманарев
Дата: 29.03.2003

статье. Помнится тогда лобовая замена lib на dll привела к приросту производительности в разы.

Здравствуйте, Sheridan, Вы писали:

S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Кеширование дало самый ощутимый прирост производительности.
Еще пакетная аллокация кучи мелких объектов.
В текущем проекте вообще думаю распоточить всю работу с чтением/записью чтобы визуал ускорить.

Здравствуйте, McQwerty, Вы писали:

MQ>

MQ>struct value
MQ>{
MQ>    int a;
MQ>    int b;
MQ>    multistring* p;
MQ>    char x [sizeof (multistring)];
MQ>};
MQ>// и когда нужно:
MQ>p = new (x) multistring;
MQ>p -> ~multistring ();
MQ>

Ненадёжный подход. Placement new и деструктор нужно явно вызывать. Выравнивание multistring не учитывается. В конструкторе/деструкторе/операторе присваивания value нужно писать много кода, обрабатывающего различные ситуации для multistring.

Когда подобные вопросы возникают, нужно всегда проверить не сделал ли кто уже такую полезную штуку за нас. И в данном случае, это уже было сделано в виде boost::optional, в котором все случаи учитываются, а интерфейс гораздо более надёжен. Там даже есть возможность создания объекта in place, во избежание лишних копий.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Было как то что некоторые операции над обьектами выполнялись несколько десятков раз из совершенно разных мест модуля за один проход основного цикла модуля (по логике все было правильно но перформанс страдал) — помог конвеер операций.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

В одной опенсорсной библиотеке, в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.
Только вот беда — опечатались в возвращаемом типе, и вместо ссылки возвращали копию члена (а член был развесистым контейнером).
Оптимизация была в локальном фиксе исходника либы и в отсылке патча разработчикам

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

* Если обобщать, то несколько раз (и в несколько раз) помогало кэширование результатов в разном виде, а также иные способы уклонения от лишних вычислений (вроде выноса лишних вычислений из цикла).
* Несколько раз удавалось сделать более умный обход контейнера (когда нужно было найти определенный элемент).
* Иногда после модификации алгоритма приходилось менять тип контейнера (список — вектор — дерево).
* Особняком стоит случай, когда замена компилфтора MSVC 7.1 на Intel C++ Compiler 8.1 ускорила выполнение алогрима на 10-15 % (в зависимости от параметров алгоритма). Поскольку в общей сложности алгоритм молотил несколько суток, то прирост был очень приятным, тем более что замена прошла без серьезных усилий. Потом тот же проект собираля на MinGW gcc 4.x.x — было на 5-10 % медленнее чем MSVC 7.1.
* Говорят чувствительный прирост дает учет кэширования данных, но у меня пока потребности в этом не возникало.

А с какой целью интересуетесь?