Здравствуйте, jazzer, Вы писали:
J>в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.
[Off-topic]
Именно "в соответствиями с принципами ООП"? IMHO в большинстве случаев члены-данные лучше делать скрытыми независимо от приверженности принципам ООП.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Заменил QT на WTL. Стало все летать.
А так про что вопрос конкретно? Про какую часть софта? И что такое этот софт вообще делает?
Здравствуйте, Sheridan, Вы писали:
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Совокупкость взаимосвязанных контейнеров с указателями на элементы контейнеров и общим размеров в десятки мегабайт нужно было грузить в память при старте программы и сохранять на диске при ее завершении. Написал "аллокатор", выделявший память из одного большого куска памяти, читавшегося из файла за один раз, и шаблон класса RelPtr (относительный указатель), заменив на экземпляры соответствующих шаблонных классов все указатели в контейнерах. Ускорение было на 2-3 порядка, программа грузилась тогда (10 лет назад) за несколько секунд вместо десятков минут.
Контейнеры были не STL, хотя попробовал сначала использовать их, но оказалось, что std::allocator тогда (VC6) заменить так, как надо, было нельзя.
Подобное, хотя конечно намного более универсальное решение использует теперь Boost.Interprocess, причем к моему удивлению там тоже используется "относительный указатель", хранящий смещение от своего собственного адреса, а не "указатель", хранящий смещение от некого адреса загрузки. Я выбрал решение с относительным указателем просто потому, что его проще было реализовать, и был почти уверен, что эффективнее другое. Но попробовать руки не дошли. До сих пор. (Эта реализация все еще используется, и полтора года назад я уже пытался объяснить кому надо, что неплохо бы переписать ее с использованием Boost.Interprocess, но похоже будет как всегда...)
Здравствуйте, Sheridan, Вы писали:
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
После работы с профайлером, мемоизации, устранении повторных вычислений на тестовом скрипте компилятор стал работать вместо ~2 минут ~0.1 секунды.
Здравствуйте, WolfHound, Вы писали:
WH>Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.
Да, был такой случай. Замена библиотечного метода транспонирования снимка на оптимизированный под кэш дала 10 кратный прирост на больших снимках (40Мб).
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
В частовызываемой функции заменил сложение строк на стрингбилдер. Эффект был буквально ошеломительным.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Да, было увеличение throughput раз в 10. Поставили правильный innodb_buffer_pool_size.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Использование "ленивых вычислений" (по Мейерсу). Например, есть развесистая древовидная структура данных. Отображать в списке (QTreeView) только верхний уровень и рисовать плюсики. Если юзер захотел развернуть item, тогда подгружать данные для этого итема. Получаются небольшие тормоза при развертке, но в целом при загрузке все ускорилось во много раз.
Ну и понятно кэширование рулит.
И еще рулят грамотные запросы к БД. Лучше сделать один запрос с LEFT OUTER JOIN чем много запросов в цикле.
Переезд с Qt 4.4 на Qt 4.5 тоже ускоряет работу софта.
Давным-давно на Delphi 5(?) / Interbase 5 переделывал генератор итогового отчёта по некой базе денных. Перенёс логику из клиентского кода в хранимую процедуру (с использованием временных таблиц) для экономии на трафике и создании всех этих объектных обёрток. Ускорение — с 40 минут до 5 секунд.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Оригинальный алгоритм, скачанный с Интернета, работал 6 секунд. После моих модификаций работает 400-500 мсек на 2-ядерной машине и 200-300 — на четырехядерной. По существу я алгоритм не менял, но изменил расположение матрицы в памяти, порядок прохода в ней циклами и добавил многопоточность.
А еще см. вот это. Там вообще-то речь о другом, но есть сравнение VirtualAlloc и new.
Здравствуйте, dmz, Вы писали:
dmz>После работы с профайлером, мемоизации, устранении повторных вычислений на тестовом скрипте компилятор стал работать вместо ~2 минут ~0.1 секунды.
Уже второй человек упомянул профайлер из 20. Однако, как раз с этого нужно начинать, потому так оптимизация вслепую — просто потеря времени.
У меня был случай, когда профайлер показал необычно много времени, проведенном в функциях lock/unlock. Оказалось, что это происходило в многопоточном property map. Но в превалирующем сценарии properties в него в записывались только со старта программы, а потом только читались. Хотя могли быть и другие properties, которые могли писаться когда угодно. Тогда было сделано так: property map был разбит на две части. Первоначальный набор properties помещался в read-only часть (которая не требовала синхронизации), а все остальные в read-write (где вызывались lock/unlock, как обычно). После этого lock/unlock навсегда исчезли из профайла.
Ещё было много других случаев, но многие из них слишком долго описывать.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
1. После профайлинга и code review обнаружил неправильную блокировку интервала в коллекции. Уменьшение диапазона ускорило в ~x12
2. Замена транспортного уровня с RPC на message queue увеличило производительность в среднем в x20
3. Когда-то давно... перееписывание ASM-алгоритма для альфаблендинга c использованием MMX увеличило скорость в x3.5
а вообще дофига всего
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, WolfHound, Вы писали:
WH>Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.
Как это делается? Ммм, например, при какой-либо обработке изображения на 40 Мб. Разбивать её на блоки меньшие кэша и независимо их обрабатывать? А если независимо нельзя? Может, есть литература по теме?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model и выставил использование SSE2.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, jazzer, Вы писали:
J>>в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.
I>[Off-topic] I>Именно "в соответствиями с принципами ООП"? IMHO в большинстве случаев члены-данные лучше делать скрытыми независимо от приверженности принципам ООП.
инкапсуляция — это один их трех канонических принципов ООП
ЗЫ Насчет большинства случаев — согласен. Вот если б ты сказал "всегда" — вот тут был бы флейм
Здравствуйте, AndrewJD, Вы писали:
N>>Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model AJD>И какую выставил?