Re[2]: О производительности
От: igna Россия  
Дата: 16.08.09 19:31
Оценка: 1 (1) +3
Здравствуйте, Mamut, Вы писали:

M>Замена O(n^2) хотя бы на O(n) уже даст тебе на порядок более быстрый алгоритм


Хм, на порядок... Или на два, или на три, или такой же по скорости, или на порядок более медленный. В зависимости от конкретных обстоятельств.
Re[2]: О производительности
От: igna Россия  
Дата: 16.08.09 19:37
Оценка:
Здравствуйте, jazzer, Вы писали:

J>в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.


[Off-topic]
Именно "в соответствиями с принципами ООП"? IMHO в большинстве случаев члены-данные лучше делать скрытыми независимо от приверженности принципам ООП.
Re: О производительности
От: c-smile Канада http://terrainformatica.com
Дата: 16.08.09 19:49
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

Заменил QT на WTL. Стало все летать.

А так про что вопрос конкретно? Про какую часть софта? И что такое этот софт вообще делает?
Re: О производительности
От: igna Россия  
Дата: 16.08.09 20:08
Оценка: 9 (2)
Здравствуйте, Sheridan, Вы писали:

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


Совокупкость взаимосвязанных контейнеров с указателями на элементы контейнеров и общим размеров в десятки мегабайт нужно было грузить в память при старте программы и сохранять на диске при ее завершении. Написал "аллокатор", выделявший память из одного большого куска памяти, читавшегося из файла за один раз, и шаблон класса RelPtr (относительный указатель), заменив на экземпляры соответствующих шаблонных классов все указатели в контейнерах. Ускорение было на 2-3 порядка, программа грузилась тогда (10 лет назад) за несколько секунд вместо десятков минут.

Контейнеры были не STL, хотя попробовал сначала использовать их, но оказалось, что std::allocator тогда (VC6) заменить так, как надо, было нельзя.

Подобное, хотя конечно намного более универсальное решение использует теперь Boost.Interprocess, причем к моему удивлению там тоже используется "относительный указатель", хранящий смещение от своего собственного адреса, а не "указатель", хранящий смещение от некого адреса загрузки. Я выбрал решение с относительным указателем просто потому, что его проще было реализовать, и был почти уверен, что эффективнее другое. Но попробовать руки не дошли. До сих пор. (Эта реализация все еще используется, и полтора года назад я уже пытался объяснить кому надо, что неплохо бы переписать ее с использованием Boost.Interprocess, но похоже будет как всегда...)
Re: О производительности
От: WolfHound  
Дата: 16.08.09 20:42
Оценка: 2 (1)
Здравствуйте, Sheridan, Вы писали:

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

Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: О производительности
От: dmz Россия  
Дата: 17.08.09 02:34
Оценка:
S>Приветствую!
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

После работы с профайлером, мемоизации, устранении повторных вычислений на тестовом скрипте компилятор стал работать вместо ~2 минут ~0.1 секунды.
Re[2]: О производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.08.09 04:20
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.


Да, был такой случай. Замена библиотечного метода транспонирования снимка на оптимизированный под кэш дала 10 кратный прирост на больших снимках (40Мб).
Re: О производительности
От: anton_t Россия  
Дата: 17.08.09 04:45
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

В частовызываемой функции заменил сложение строк на стрингбилдер. Эффект был буквально ошеломительным.
Re: О производительности
От: WFrag США  
Дата: 17.08.09 04:48
Оценка: 2 (1)
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

Да, было увеличение throughput раз в 10. Поставили правильный innodb_buffer_pool_size.
Re: О производительности
От: Рысцов Денис  
Дата: 17.08.09 05:23
Оценка: 7 (2)
S>Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации.

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

INSERT INTO some_table(some_column, another_column) VALUES (some_value_a,another_value_a); 
INSERT INTO some_table(some_column, another_column) VALUES (some_value_b,another_value_b); 
INSERT INTO some_table(some_column, another_column) VALUES (some_value_c,another_value_c); 
...


на

INSERT INTO some_table(some_column, another_column)  
VALUES
  (some_value_a,another_value_a),
  (some_value_b,another_value_b),
  (some_value_c,another_value_c),   
  ...


Скорость работы увеличилась с 30 часов до 13 минут.
Re: О производительности
От: lazyrun  
Дата: 17.08.09 06:03
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

Использование "ленивых вычислений" (по Мейерсу). Например, есть развесистая древовидная структура данных. Отображать в списке (QTreeView) только верхний уровень и рисовать плюсики. Если юзер захотел развернуть item, тогда подгружать данные для этого итема. Получаются небольшие тормоза при развертке, но в целом при загрузке все ускорилось во много раз.

Ну и понятно кэширование рулит.
И еще рулят грамотные запросы к БД. Лучше сделать один запрос с LEFT OUTER JOIN чем много запросов в цикле.
Переезд с Qt 4.4 на Qt 4.5 тоже ускоряет работу софта.
Re: О производительности
От: dimgel Россия http://dimgel.ru/
Дата: 17.08.09 06:59
Оценка:
Hello, Sheridan,

Давным-давно на Delphi 5(?) / Interbase 5 переделывал генератор итогового отчёта по некой базе денных. Перенёс логику из клиентского кода в хранимую процедуру (с использованием временных таблиц) для экономии на трафике и создании всех этих объектных обёрток. Ускорение — с 40 минут до 5 секунд.
avalon 1.0rc2 rev 299, zlib 1.2.3
Re: О производительности
От: Pavel Dvorkin Россия  
Дата: 17.08.09 08:08
Оценка: 7 (1)
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

Оригинальный алгоритм, скачанный с Интернета, работал 6 секунд. После моих модификаций работает 400-500 мсек на 2-ядерной машине и 200-300 — на четырехядерной. По существу я алгоритм не менял, но изменил расположение матрицы в памяти, порядок прохода в ней циклами и добавил многопоточность.

А еще см. вот это. Там вообще-то речь о другом, но есть сравнение VirtualAlloc и new.

http://rsdn.ru/forum/winapi/2791128.1.aspx
Автор: Pavel Dvorkin
Дата: 10.01.08
With best regards
Pavel Dvorkin
Re[2]: О производительности
От: alexeiz  
Дата: 17.08.09 08:34
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>После работы с профайлером, мемоизации, устранении повторных вычислений на тестовом скрипте компилятор стал работать вместо ~2 минут ~0.1 секунды.


Уже второй человек упомянул профайлер из 20. Однако, как раз с этого нужно начинать, потому так оптимизация вслепую — просто потеря времени.

У меня был случай, когда профайлер показал необычно много времени, проведенном в функциях lock/unlock. Оказалось, что это происходило в многопоточном property map. Но в превалирующем сценарии properties в него в записывались только со старта программы, а потом только читались. Хотя могли быть и другие properties, которые могли писаться когда угодно. Тогда было сделано так: property map был разбит на две части. Первоначальный набор properties помещался в read-only часть (которая не требовала синхронизации), а все остальные в read-write (где вызывались lock/unlock, как обычно). После этого lock/unlock навсегда исчезли из профайла.

Ещё было много других случаев, но многие из них слишком долго описывать.
Re: О производительности
От: akarinsky Россия  
Дата: 17.08.09 10:00
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

1. После профайлинга и code review обнаружил неправильную блокировку интервала в коллекции. Уменьшение диапазона ускорило в ~x12
2. Замена транспортного уровня с RPC на message queue увеличило производительность в среднем в x20
3. Когда-то давно... перееписывание ASM-алгоритма для альфаблендинга c использованием MMX увеличило скорость в x3.5

а вообще дофига всего
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Re[2]: О производительности
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.08.09 10:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Например укатывание алгоритма под кешь процессора. Ускорение от 2 до 100 раз.


Как это делается? Ммм, например, при какой-либо обработке изображения на 40 Мб. Разбивать её на блоки меньшие кэша и независимо их обрабатывать? А если независимо нельзя? Может, есть литература по теме?
Re: О производительности
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.08.09 10:20
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Приветствую!

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

Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model и выставил использование SSE2.
Re[3]: О производительности
От: jazzer Россия Skype: enerjazzer
Дата: 17.08.09 11:28
Оценка:
Здравствуйте, igna, Вы писали:

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


J>>в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.


I>[Off-topic]

I>Именно "в соответствиями с принципами ООП"? IMHO в большинстве случаев члены-данные лучше делать скрытыми независимо от приверженности принципам ООП.

инкапсуляция — это один их трех канонических принципов ООП

ЗЫ Насчет большинства случаев — согласен. Вот если б ты сказал "всегда" — вот тут был бы флейм
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[2]: О производительности
От: AndrewJD США  
Дата: 17.08.09 11:49
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model

И какую выставил?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[3]: О производительности
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.08.09 12:02
Оценка:
Здравствуйте, AndrewJD, Вы писали:

N>>Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model

AJD>И какую выставил?

Fast
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.