О производительности
От: Sheridan Россия  
Дата: 14.08.09 08:22
Оценка: :))) :))) :))
Приветствую!
Люди а поделитесь опытом — у кого-ть было когда-ть заметное улучшение производительности софта после какойтотам оптимизации. Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.
avalon 1.0rc2 rev 299, zlib 1.2.3
build date: 14.08.2009 10:49:13 MSD +04:00
Qt 4.5.2

17.08.09 00:42: Перенесено модератором из 'C/C++' — WolfHound
Matrix has you...
Re: О производительности
От: Alexander G Украина  
Дата: 14.08.09 08:44
Оценка: 29 (5) +1
Здравствуйте, Sheridan, Вы писали:

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

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

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

Из впечатлившего — вставка большой кучи узлов в виндовый Treeview тормозит с TVI_LAST, но примелемо работает с TVI_FIRST. Там, видать, односвязный список.
Русский военный корабль идёт ко дну!
Re: Уважаемые смеющиеся, а чего смешного я сказал?
От: Alexander G Украина  
Дата: 18.08.09 22:49
Оценка: 1 (1) +5
Здравствуйте, Sheridan, Вы писали:

S>Помоему очень даже интересный топик получился...


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


Это примерно то же, что спросить

Люди, а кто-то из вас использовал вложенные циклы?

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

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


Хм, на порядок... Или на два, или на три, или такой же по скорости, или на порядок более медленный. В зависимости от конкретных обстоятельств.
Re[5]: О производительности
От: yumi  
Дата: 18.08.09 10:32
Оценка: 1 (1) +2
Здравствуйте, gandjustas, Вы писали:

Y>>Ага, и приносят кучу новых


G>Каких например?


Ну например, накопление цепочки не вычисленных операций, которое в самый не подходящий момент начинает вычисляться. Сложность отладки, непредсказуемость. Просто я сейчас как раз таки занимаюсь наоборот, оптимизацией скорости посредством избавления от ленивости.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re: О производительности
От: denisko http://sdeniskos.blogspot.com/
Дата: 19.08.09 18:16
Оценка: :)))
Здравствуйте, Sheridan, Вы писали:

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

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

А можно я сразу к сути вопроса.
Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
<Подпись удалена модератором>
Re[5]: Для самообразования — Agner Fog
От: SergeCpp Россия http://zoozahita.ru
Дата: 19.08.09 07:50
Оценка: 18 (2)
N>...просто интересно интересно как такая оптимизация производится: есть готовая методика или просто рекомендации. Для самообразования.

У Agner Fog были?

http://www.agner.org/optimize/#manuals
http://zoozahita.ruБездомные животные Екатеринбурга ищут хозяев
Agner Fog
Re: О производительности
От: igna Россия  
Дата: 16.08.09 20:08
Оценка: 9 (2)
Здравствуйте, Sheridan, Вы писали:

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


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

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

Подобное, хотя конечно намного более универсальное решение использует теперь Boost.Interprocess, причем к моему удивлению там тоже используется "относительный указатель", хранящий смещение от своего собственного адреса, а не "указатель", хранящий смещение от некого адреса загрузки. Я выбрал решение с относительным указателем просто потому, что его проще было реализовать, и был почти уверен, что эффективнее другое. Но попробовать руки не дошли. До сих пор. (Эта реализация все еще используется, и полтора года назад я уже пытался объяснить кому надо, что неплохо бы переписать ее с использованием Boost.Interprocess, но похоже будет как всегда...)
Re[3]: О производительности
От: Bell Россия  
Дата: 14.08.09 08:53
Оценка: 7 (1) +1
Здравствуйте, Sheridan, Вы писали:

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


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


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

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

...

А вообще сложно перечислять — каждый случай по-своему уникален Перечислять все лень, а пытаться писать обо всех сразу — получаются общие слова...
Любите книгу — источник знаний (с) М.Горький
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: О производительности
От: c-smile Канада http://terrainformatica.com
Дата: 16.08.09 19:49
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

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

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

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

А так про что вопрос конкретно? Про какую часть софта? И что такое этот софт вообще делает?
Re: О производительности
От: anton_t Россия  
Дата: 17.08.09 04:45
Оценка: :))
Здравствуйте, Sheridan, Вы писали:

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

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

В частовызываемой функции заменил сложение строк на стрингбилдер. Эффект был буквально ошеломительным.
Re: О производительности
От: Cadet  
Дата: 17.08.09 14:54
Оценка: :))
Ну где же, где примеры наступления счастья от переписывания всего на С++???
... << RSDN@Home 1.2.0 alpha 4 rev. 1238>>
http://www.rsdn.org/File/13118/csharp.gif
Re[2]: О производительности
От: Sheridan Россия  
Дата: 17.08.09 18:26
Оценка: -1 :)
Приветствую, Cadet, вы писали:

C> Ну где же, где примеры наступления счастья от переписывания всего на С++???

Ну для этого надо учиться и тратить драгоценное время, которое можно потратить на зарабатывание денег.
Поэтому таких примеров не будет.
Хотя... В подпись посмотри
avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 17.08.2009 15:04:24 MSD +04:00
Qt 4.5.2
Matrix has you...
Re[3]: О производительности
От: yumi  
Дата: 18.08.09 08:19
Оценка: +1 :)
Здравствуйте, gandjustas, Вы писали:

G>ЗЫ. ленивые вычисления позволяют избавить от этой проблемы.


Ага, и приносят кучу новых
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[7]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 21.08.09 18:16
Оценка: 10 (1)
Здравствуйте, MxKazan, Вы писали:

MK> Я же просил примеры кода, а не литературу,


В том файле смотри главу 6, там конкретные приемы и примеры кода.
Re: О производительности
От: sc Россия  
Дата: 14.08.09 09:11
Оценка: 7 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

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

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

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

жил-был огромный класс, который кушал много памяти и требовал много времени на копирование-конструирование, жил он в коде для embedded device'а, имел много экземпляров и печалил несказанно он многия разработчиков и проектных менеджеров.
А потом его переписали с помощью идиомы COW.
И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.
Re: О производительности
От: Mamut Швеция http://dmitriid.com
Дата: 14.08.09 10:26
Оценка: 7 (1)
Здравствуйте, 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 секунд.


dmitriid.comGitHubLinkedIn
Re: О производительности
От: little_alex  
Дата: 14.08.09 10:41
Оценка: 7 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

Был у нас забавный случай. QListView, заполнялся строчками. Для каждой строчки создавалась картинка QPixmap ( из файла загружалась ). Это было медленно и, скорее всего, много памяти отъедало. Потом это нашли и поменяли на один QPixmap, который устанавливался на каждую строчку. Скорость прокрутки ListView возросла даже на глаз.
Re: О производительности
От: Vamp Россия  
Дата: 14.08.09 13:18
Оценка: 7 (1)
Из того, что сейчас помню — сортировка списков списков. В первоначальном варианте выполнялось глубокое копирование, когда заметили — заменили на swap голов.
Да здравствует мыло душистое и веревка пушистая.
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: О производительности
От: Kore Sar  
Дата: 20.08.09 13:32
Оценка: 7 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

О! Какая благодатная тема!
На своём проекте я ускорил работу приложения примерно в 100 раз. И уменьшил расход памяти примерно в 10 раз.

Основная причина тормозов — идиоты разработчики.
1) Делали много ненужных подсчетов медленными методами.
2) Часто выделяли и освобождали ненужные куски памяти.
3) Слишком много данных хранили и обрабатывали как строки, хотя мжено было использовать числа.
4) Много раз бегали по одному и тому же массиву в поисках одного и того же значения.
5) Всё происходило на многоядерных серверах, но одним потоком.

Что я сделал.
1) Подсчеты теперь производятся только тогда, когда появляется небоходимость. Алгоритмы сделал быстрыми. (Ускорение раза в 4.)
2) Память теперь еще раз не выделялась, а юзалась уже имеющаяся. Местами, где можно было, перешел от огромных буферов к потокам. (Ускорение раза в 2.)
3) Где использовали как ключ строку вида "1234567890", там перешли на int. (Ускорение раза в 2.)
4) Сделал кеширование результатов в некоторых местах. (Ускорение раза в 2-5.)
5) Заюзал многопоточность. (Ускорение максимум в 14 раз.
Автор: Kore Sar
Дата: 09.12.08
)



Основаня причина расхода памяти — тоже идиоты разработчики.
1) Чтобы подсчитать одно (из сотен) число они исполозовали половину из всей выделеной ими памяти. Т.е. один из 2-х ГБ служил для единственной цифры.
2) Использовались огромные буферы.
3) Использовали строки в тех местах, где можно было int.
4) Одна и та же информация хранилась как почти идентичная копия в другом месте для других целей.

Что я сделал.
1) Спросил можно ли отказаться от этой единственной цифры совсем. Начальники сказали что можно. И я удалил её к чертям. -50%
2) Перешел кое-где от буферов к потокам. — Исчезли так называемые пиковые нагрузки, когда к выделеной памяти выделялось еще 200%.
3) Заюзал int-ы где только можно. Еще -50%.
4) Создали одно хранилище информации для всех целей. Еще -50%.
Re: О производительности
От: LaPerouse  
Дата: 04.09.09 08:07
Оценка: 6 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

Недавно провел серию оптимизаций, результатом которых было ускорение кода более чем в 1000 раз и существенное сокращение потребляемой памяти.

1. Переписал три алгоритма (осбенно заметным был эффект от переписывания алгоритма O(n2) на O(n))
2. Реализовал кэш, в результате чего последующие алгоритмы обхода графообразных структур могли пользоваться статистикой, накопленной во время работы предыдущих алгоритмов.
3. Произвел рефакторинг, в результате которого были устранены некоторые идиотские решения, сделанные мной на скорую руку по принципу "чтоб работало".
4. Исправил одну ошибку, производительность тут же возросла где-то на 20 процентов.
5. !!! Самое существенное ускорение прозошло от предобработки входного графа. Преобразовал его в соответствии с принципами предметной области в другой граф, по коротому уже отрабатывали остальные алгоритмы. Потом результаты работы этих алгоритмов поднимались до исходного графа по истории преобразований. Граф с 100000 вершин в зависимости от топологии может преобразовываться в граф с количеством вершин 100-1000. В результате чего достигается феноменальное ускорение! Надо сказать, что это стало возможным благодаря введению истории преобразований (которую поддерживает почти каждый алгоритм) и иммутабельным алгоритмам (не изменяющим состояние исходного графа).
6. Реализовал способ выборки подходящего итерационного процесса в зависимости от входных условий. Эта часть надо сказать еще толком не работает, поэтому эффект в ускорении незначительный (правильнее сказать — нестабильный).
7. Применил некоторые оптимизации, подсказанные предметной областью.
Социализм — это власть трудящихся и централизованная плановая экономика.
Re: О производительности
От: zaufi Земля  
Дата: 14.08.09 17:40
Оценка: 2 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

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

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

* еще один яркий случай описан здесь
Автор: zaufi
Дата: 01.12.06


* в далекие (уже) времена когда мы переходили на только начинающий стабилизироваться gcc 3.0 пересобрав на наш проект к ключиками для амд атлона и сравнив их с собранным под пень4 получили 20-30% увеличение производительности (погуглив оказалось что амдшные парни плотно работали с гцц тимом над правильным шедулером) -- потом мы стали покупать больше компов с амд )
Re: О производительности
От: rg45 СССР  
Дата: 14.08.09 18:30
Оценка: 2 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

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

Из неалгоритмических улучшений производительности очень запомнился случай, когда начал работать на стыке managed-unmanaged кода. В первый момент я был шокирован, когда увидел в профиляторе громадное количество managed-unmanaged переходов в совершенно неожиданных участках кода. Тогда я еще не был в курсе некоторых особенностей, которые хорошо описаны в этой
Автор(ы): Максим Шеманарев
Дата: 29.03.2003
статье. Помнится тогда лобовая замена lib на dll привела к приросту производительности в разы.
--
Re: О производительности
От: WolfHound  
Дата: 16.08.09 20:42
Оценка: 2 (1)
Здравствуйте, Sheridan, Вы писали:

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

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

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

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

Да, было увеличение throughput раз в 10. Поставили правильный innodb_buffer_pool_size.
Re[4]: О производительности
От: FR  
Дата: 05.09.09 05:30
Оценка: 2 (1)
Здравствуйте, LaPerouse, Вы писали:

DM>>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.


LP>Это прямо-таки удивительно (если без изменений алгоритма).


В декларативном есть обсуждение.
А так ничего удивительного, достаточно или кучи мелких выделений памяти (у OCaml очень шустрый GC а стандартные аллокаторы C++ особенно VC обычно очень плохие) или как у него все логика транслируется в составное замыкание, если прямо переписать на C++ заменив замыкания объектами, то тоже получим тормоза, во первых из-за той же памяти во вторых из-за того что замыкания оптимизируются и инлайнятся компилятором OCamla гораздо лучше чем объекты компиляторами C++.
Re: О производительности
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 18.08.09 07:52
Оценка: 1 (1)
Здравствуйте, Sheridan, Вы писали:

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


У оптимизации производительности два бога — кэширование и индексирование. Плюс к тому, конечно, есть толпа божков в виде оптимальных алгоритмов.
Кэширование заменяет тяжёлые операции лёгкими, а индексирование превращает O(N) в O(Ln N), O(N*N) в O(N*Ln N) и т.п.

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

Практически любую программу, оптимизацией которой не занимались специально, долго и вдумчиво, удаётся разогнать по крайней мере раза в два. И попутно понизить класс тормознутости (это самое "О").
Re[5]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 21.08.09 04:29
Оценка: 1 (1)
Здравствуйте, MxKazan, Вы писали:

WH>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.

MK>А можно конкретнее?

http://people.redhat.com/drepper/cpumemory.pdf
Re: О производительности
От: Bell Россия  
Дата: 14.08.09 08:27
Оценка: +1
Здравствуйте, Sheridan, Вы писали:

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

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

S>Интересует именно причина возростания производительности, тоесть изза чего были тормоза и как поправили.

Причина возрастания производительности — проведенная оптимизация, тут все просто. А вот насчет причин... Случаев было много и разных. Перечислять все?
Любите книгу — источник знаний (с) М.Горький
Уважаемые смеющиеся, а чего смешного я сказал?
От: Sheridan Россия  
Дата: 18.08.09 21:01
Оценка: +1
Помоему очень даже интересный топик получился...
avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 18.08.2009 18:11:54 MSD +04:00
Qt 4.5.2
Matrix has you...
Re[3]: О производительности
От: Flying Dutchman Украина  
Дата: 18.08.09 23:12
Оценка: :)
Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, Flying Dutchman, Вы писали:

Х>если "ks" это фиксированый префикс, то почему бы не залукапить полностью все комбинации?

Да, интересная идея — хотя исходники великоваты получатся (хотя можно их, конечно, сгенерироваь автоматически).

X>Выйдет меньше чем 16 кб, или ограничения по памяти очень жёсткие (микроконтроллеры)?


Да нет, у нас использовался процессор Motorola 68000 c 4 или 8 Mb памяти, так что это было бы не критично. В принципе, слабооптимизированная версия нас устроила. Впоследствии даже выяснилось, что даже неоптимизированная версия не сильно влияла на производительность, поскольку этот код использовался достаточно редко (конечно, там была потенциальная опасность из-за того, что функция sprintf производит вызов malloc, но за время долгой эксплуатации программы проблем не было).
http://www.linkedin.com/img/webpromo/btn_liprofile_blue_80x15.gif
Re[5]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 05.09.09 17:48
Оценка: :)
Здравствуйте, FR, Вы писали:

LP>>Это прямо-таки удивительно (если без изменений алгоритма).


FR>В декларативном есть обсуждение.


Это ты про 2009 вспомнил, а тут речь про задание 2007-го — где ДНК в РНК транслировалась. Там просто действительно очень много выделений памяти было, оттого и разница в скорости.
Re[2]: О производительности
От: Sheridan Россия  
Дата: 14.08.09 08:31
Оценка:
Приветствую, Bell, вы писали:

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


Ну хотябы самые яркие
avalon 1.0rc2 rev 299, zlib 1.2.3
build date: 14.08.2009 10:49:13 MSD +04:00
Qt 4.5.2
Matrix has you...
Re: О производительности
От: alzt  
Дата: 14.08.09 14:10
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Вспомнить сложно. И ещё сложнее описать.
Самый яркий случай — ускорил одну функцию примерно в 5 тысяч раз.
Эта функция вызывалась в меню и в результате на больших моделях программа недопустимо тормозила — более 5 секунд на открывание контекстного меню.
Причина — плохой алгоритм, проверялся сам элемент и все его дочерние элементы на наличие некоторого стереотипа.
Переписал по другому — находил все экземпляры этого стереотипа и кому он принадлежит, а далее проверял, что он не принадлежат искомому элементу.
Re[3]: О производительности
От: McQwerty Россия  
Дата: 14.08.09 15:28
Оценка:
Здравствуйте, 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 ();

В дальнейшем неоднократно использовали этот приём в аналогичных ситуациях.
Re[4]: О производительности
От: Vamp Россия  
Дата: 14.08.09 15:45
Оценка:
MQ>p = new (x) multistring;
MQ>p -> ~multistring ();

А менеджер динамической памяти поменять не пробовали?
Да здравствует мыло душистое и веревка пушистая.
Re: О производительности
От: zitz  
Дата: 14.08.09 18:41
Оценка:
Здравствуйте, Sheridan, Вы писали:

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


Кеширование дало самый ощутимый прирост производительности.
Еще пакетная аллокация кучи мелких объектов.
В текущем проекте вообще думаю распоточить всю работу с чтением/записью чтобы визуал ускорить.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[4]: О производительности
От: alexeiz  
Дата: 14.08.09 21:01
Оценка:
Здравствуйте, 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, во избежание лишних копий.
Re: О производительности
От: Аноним  
Дата: 14.08.09 21:46
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Было как то что некоторые операции над обьектами выполнялись несколько десятков раз из совершенно разных мест модуля за один проход основного цикла модуля (по логике все было правильно но перформанс страдал) — помог конвеер операций.
Re: О производительности
От: jazzer Россия Skype: enerjazzer
Дата: 16.08.09 17:15
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

В одной опенсорсной библиотеке, в соответствиями с принципами ООП, член сделали скрытым и сделали к нему геттер.
Только вот беда — опечатались в возвращаемом типе, и вместо ссылки возвращали копию члена (а член был развесистым контейнером).
Оптимизация была в локальном фиксе исходника либы и в отсылке патча разработчикам
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: О производительности
От: Mazay Россия  
Дата: 16.08.09 17:55
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

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

А с какой целью интересуетесь?
Главное гармония ...
Re[2]: О производительности
От: igna Россия  
Дата: 16.08.09 19:37
Оценка:
Здравствуйте, jazzer, Вы писали:

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


[Off-topic]
Именно "в соответствиями с принципами ООП"? IMHO в большинстве случаев члены-данные лучше делать скрытыми независимо от приверженности принципам ООП.
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: О производительности
От: 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[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 Мб. Разбивать её на блоки меньшие кэша и независимо их обрабатывать? А если независимо нельзя? Может, есть литература по теме?
https://elibrary.ru/author_counter.aspx?id=875549
Re: О производительности
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.08.09 10:20
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Поиграл с опциями компилятора (MS VC 7.1), ускорилось в 2 раза: изменил floating point model и выставил использование SSE2.
https://elibrary.ru/author_counter.aspx?id=875549
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
https://elibrary.ru/author_counter.aspx?id=875549
Re[3]: О производительности
От: WolfHound  
Дата: 17.08.09 14:10
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>Как это делается?

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

N>Ммм, например, при какой-либо обработке изображения на 40 Мб.

На обработке изображений у меня этими методами получалось разогнать в 2-3 раза.

N>Разбивать её на блоки меньшие кэша и независимо их обрабатывать? А если независимо нельзя?

А что за алгоритм то? Код показать можешь?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: О производительности
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 17.08.09 16:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

N>>Разбивать её на блоки меньшие кэша и независимо их обрабатывать? А если независимо нельзя?

WH>А что за алгоритм то? Код показать можешь?

У меня изображения в основном 384х288 и интеловская VTune промахов не показывает. Мне просто интересно интересно как такая оптимизация производится: есть готовая методика или просто рекомендации. Для самообразования.
https://elibrary.ru/author_counter.aspx?id=875549
Re[2]: О производительности
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 18.08.09 03:08
Оценка:
Здравствуйте, Cadet, Вы писали:

C>Ну где же, где примеры наступления счастья от переписывания всего на С++???


Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.
Re: О производительности
От: geniepro http://geniepro.livejournal.com/
Дата: 18.08.09 04:34
Оценка:
Здравствуйте, Sheridan, Вы писали:

Пара ускорений в 50 раз:

1. Поиск в таблице dbf (через BDE). Сначала делал фильтрацией, обнаружились тормоза на количествах запросов. Заменил на поиск через процедуру Locate -- поиск в 50 раз ускорился, хотя теперь поиск будет ломаться, если в таблице есть удалёные записи (но это исключено, так что не важно).

2. В одной чужой тулзе, попавшей ко мне на доработку, был алгоритм загрузки данных в список, в котором список постоянно проверялся на наличие в нём загружаемого значения (данные в списке должны быть уникальны). Получилась сложность O(n^2). Вставил в это место временный упорядоченный список, получилось O(n*log n) -- на тех объёмах даных, что там были, ускорение составило более 50 раз.
Re[2]: О производительности
От: geniepro http://geniepro.livejournal.com/
Дата: 18.08.09 05:00
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


Типа такого было: нашёл простой в применении исходник, реализующий AES-256, так там было два варианта расчётов -- табличный и процедурный. Причём константа, переключающая режим на табличный (BACK_TO_TABLES), была закоментирована. Раскомментировал её -- шифрование/дешифрование ускорилось раз в сто, не меньше...

* Byte-oriented AES-256 implementation.
* All lookup tables replaced with 'on the fly' calculations.
*
* Copyright (c) 2007-2009 Ilya O. Levin, http://www.literatecode.com
* Other contributors: Hal Finney

Вот это вот изменение "All lookup tables replaced with 'on the fly' calculations." и замедлило алгоритмы на два порядка...
Re[2]: О производительности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.08.09 08:00
Оценка:
Здравствуйте, Voblin, Вы писали:

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


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


V>У оптимизации производительности два бога — кэширование и индексирование. Плюс к тому, конечно, есть толпа божков в виде оптимальных алгоритмов.

V>Кэширование заменяет тяжёлые операции лёгкими, а индексирование превращает O(N) в O(Ln N), O(N*N) в O(N*Ln N) и т.п.

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

И тем и другим кешироанием надо пользоваться с осторожностью. Бывает так что тратится время на кеширование чего-либо, что потом не используется.

ЗЫ. ленивые вычисления позволяют избавить от этой проблемы.
Re[4]: О производительности
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.08.09 08:39
Оценка:
Здравствуйте, yumi, Вы писали:

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


G>>ЗЫ. ленивые вычисления позволяют избавить от этой проблемы.


Y>Ага, и приносят кучу новых


Каких например?
Re: О производительности
От: Flying Dutchman Украина  
Дата: 18.08.09 21:07
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Вот пример оптимизации кода на C, используемого в управляющей программе реального времени. Задача — оптимизировать следующий код:

sprintf(buffer, "%s%d,%d", "ks", number, state);


где number может принимать значения от 0 до 176, а state — от 0 до 9.

Приведенная ниже программа содержит слабо- и сильнооптимизированный варианты кода и тесты для сравнения их производительности:


/*****************************************************************************
*               includes                                                     *
*****************************************************************************/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <assert.h>

static char *number_list[] =
{
      "0",   "1",   "2",   "3",   "4",   "5",   "6",   "7",   "8",  "9",
     "10",  "11",  "12",  "13",  "14",  "15",  "16",  "17",  "18",  "19",
     "20",  "21",  "22",  "23",  "24",  "25",  "26",  "27",  "28",  "29",
     "30",  "31",  "32",  "33",  "34",  "35",  "36",  "37",  "38",  "39",
     "40",  "41",  "42",  "43",  "44",  "45",  "46",  "47",  "48",  "49",
     "50",  "51",  "52",  "53",  "54",  "55",  "56",  "57",  "58",  "59",
     "60",  "61",  "62",  "63",  "64",  "65",  "66",  "67",  "68",  "69",
     "70",  "71",  "72",  "73",  "74",  "75",  "76",  "77",  "78",  "79",
     "80",  "81",  "82",  "83",  "84",  "85",  "86",  "87",  "88",  "89",
     "90",  "91",  "92",  "93",  "94",  "95",  "96",  "97",  "98",  "99",
    "100", "101", "102", "103", "104", "105", "106", "107", "108", "109",
    "110", "111", "112", "113", "114", "115", "116", "117", "118", "119",
    "120", "121", "122", "123", "124", "125", "126", "127", "128", "129",
    "130", "131", "132", "133", "134", "135", "136", "137", "138", "139",
    "140", "141", "142", "143", "144", "145", "146", "147", "148", "149",
    "150", "151", "152", "153", "154", "155", "156", "157", "158", "159",
    "160", "161", "162", "163", "164", "165", "166", "167", "168", "169",
    "170", "171", "172", "173", "174", "175", "176",
    NULL
};

static void convert1(char* buffer, int number, int state);
static void convert2(char* buffer, int number, int state);
static void convert3(char* buffer, int number, int state);
static void convert_empty(char* buffer, int number, int state);

int main(void) {

    char buffer1[80];
    char buffer2[80];
    char buffer3[80];
    char buffer4[80];
    char control_buffer[80];
    int i;
    const long int repetitions = 10000000;
    time_t begin_time1;
    time_t begin_time2;
    time_t begin_time3;
    time_t begin_time_empty;
    time_t end_time1;
    time_t end_time2;
    time_t end_time3;
    time_t end_time_empty;
    int    time1;
    int    time2;
    int    time3;
    int    empty_time;
    int    number;
    int    state;

    number = 1;
    state  = 2;
    sprintf(control_buffer, "ks%d,%d", number, state);

    /* Control check                                                        */
    convert1(buffer1, number, state);
    assert(strcmp(buffer1, control_buffer) == 0);

    convert2(buffer2, number, state);
    assert(strcmp(buffer2, control_buffer) == 0);

    convert3(buffer3, number, state);
    assert(strcmp(buffer3, control_buffer) == 0);

    /* Time of empty function                                               */
    begin_time_empty = time(0);
    for (i=0; i < repetitions; i++) {
        convert_empty(buffer4, number, state);
    }
    end_time_empty = time(0);
    empty_time = end_time_empty - begin_time_empty;

    /* Time of not optimized function                                       */
    begin_time1 = time(0);
    for (i=0; i < repetitions; i++) {
        convert1(buffer1, number, state);
    }
    end_time1 = time(0);
    time1 = end_time1 - begin_time1;

    /* Time of optimized function                                       */
    begin_time2 = time(0);
    for (i=0; i < repetitions; i++) {
        convert2(buffer2, number, state);
    }
    end_time2 = time(0);
    time2 = end_time2 - begin_time2;

    /* Time of highly optimized function                                 */
    begin_time3 = time(0);
    for (i=0; i < repetitions; i++) {
        convert3(buffer3, number, state);
    }
    end_time3 = time(0);
    time3 = end_time3 - begin_time3;

    time1 -= empty_time;
    time2 -= empty_time;
    time3 -= empty_time;

    printf("Repetitions:      %d\n", repetitions);
    printf("Numbers:          %d %d\n", number, state);
    printf("Empty time:       %d\n", empty_time);
    printf("Not optimized:    %d\n", time1);
    printf("Optimized:        %d\n", time2);
    printf("Highly optimized: %d\n", time3);

    return (0);
}

/*--------------------------------------------------------------------------*/
/*  Not optimized version with sprintf                                      */
/*--------------------------------------------------------------------------*/
static void convert1(char* buffer, int number, int state) {
    sprintf(buffer, "%s%d,%d", "ks", number, state);
}

/*--------------------------------------------------------------------------*/
/*  Optimized version                                                       */
/*--------------------------------------------------------------------------*/
static void convert2(char* buffer, int number, int state) {
    strcpy(buffer, "ks");
    strcat(buffer, number_list[number]);
    strcat(buffer, ",");
    strcat(buffer, number_list[state]);
}

/*--------------------------------------------------------------------------*/
/*  Highly optimized version                                                */
/*--------------------------------------------------------------------------*/
static void convert3(char* buffer, int number, int state) {
    static char *numbers = "0123456789";
    char *p_current;
    char *p_from;

    /* Write "ks"                                                           */
    p_current = buffer;
    *p_current = 'k';
    p_current++;
    *p_current = 's';

    /* Write first number using unrolled strcpy                             */
    p_current++;
    for (p_from = number_list[number]; *p_from != '\0'; p_from++) {
        *p_current = *p_from;
        p_current++;
    }

    /* Write comma                                                          */
    /* p_current is already set after the last character of copied string   */
    *p_current = ',';

    /* Write second number                                                   */
    p_current++;
    *p_current = numbers[state];

    /* Write null terminator                                                */
    p_current++;
    *p_current = '\0';
}

/*--------------------------------------------------------------------------*/
/*  Empty function                                                          */
/*--------------------------------------------------------------------------*/
static void convert_empty(char* buffer, int number, int state) {

}

/*****************************************************************************
*               end of file                                                  *
*****************************************************************************/
http://www.linkedin.com/img/webpromo/btn_liprofile_blue_80x15.gif
Re[2]: О производительности
От: Хвост  
Дата: 18.08.09 22:15
Оценка:
Здравствуйте, Flying Dutchman, Вы писали:
если "ks" это фиксированый префикс, то почему бы не залукапить полностью все комбинации? Выйдет меньше чем 16 кб, или ограничения по памяти очень жёсткие (микроконтроллеры)?
People write code, programming languages don't.
Re[2]: О производительности
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.08.09 07:08
Оценка:
Здравствуйте, Flying Dutchman, Вы писали:
Какой-то у вас convert3 многословный.
static void convert3(char* buffer, int number, int state)
{
    static char *numbers = "0123456789";

    char *p_current = buffer;

    *p_current++ = 'k';
    *p_current++ = 's';

    char *p_from = number_list[number];
    while(*pFrom)    
        *p_current++ = *p_from++;

    *p_current++ = ',';

    *p_current++ = numbers[state];

    *p_current++ = '\0';
}
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[6]: Для самообразования — Agner Fog
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 19.08.09 10:19
Оценка:
Здравствуйте, SergeCpp, Вы писали:

SC>У Agner Fog были?


SC>http://www.agner.org/optimize/#manuals


Нет, спасибо.
https://elibrary.ru/author_counter.aspx?id=875549
Re[2]: О производительности
От: Vamp Россия  
Дата: 19.08.09 18:19
Оценка:
D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.
Красиво жить не запретишь.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: О производительности
От: igna Россия  
Дата: 20.08.09 01:59
Оценка:
Здравствуйте, denisko, Вы писали:

D>А можно я сразу к сути вопроса.

D>Не далее как вчера увидел на пляже красивую девушку, перед тем как приставать посмотрел на ее лицо. Уменьшил длину пиписяндра в два раза и сэкономил кучу времени. Или сегодня, увидел жену утром, существенно увеличил жесткость вышеозначенного пиписяндра.

А длину обратно скорректировать забыл?
Re[4]: О производительности
От: MxKazan Россия  
Дата: 20.08.09 16:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


N>>Как это делается?

WH>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.
А можно конкретнее? Ключевые строки до оптимизации и после.
Re[6]: О производительности
От: MxKazan Россия  
Дата: 21.08.09 14:55
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


WH>>>Ну... внимательно смотришь на алгоритм. Определяешь где у некоторого сферического кеша в вакууме(ибо они на разных процессорах ведут себя несколько по разному) будут промахи и переписываешь обращения к памяти так чтобы этих промахов было поменьше.

MK>>А можно конкретнее?

DM>http://people.redhat.com/drepper/cpumemory.pdf

Отлично. Я теперь на все вопросы в форумах по .NET буду отвечать: "http://msdn.microsoft.com/ru-ru/default.aspx" Я же просил примеры кода, а не литературу, в которой нужно разбираться. Глубоко копаться я пока не хочу, а быстро глянуть — интересно. Но если нет примеров, то ладно, нет так нет.
Re[7]: О производительности
От: cl-user  
Дата: 21.08.09 18:03
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Глубоко копаться я пока не хочу...


Нет ничего более постоянного, чем временное...
Re: О производительности
От: _Obelisk_ Россия http://www.ibm.com
Дата: 25.08.09 11:01
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Заменил алгоритм со сложностью O(n^2) на O(n* log n). Производительность, очевидно, возросла.


http://www.rsdn.org:80/File/18435/5278.png
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: О производительности
От: Hawk Россия  
Дата: 27.08.09 13:24
Оценка:
Здравствуйте, StevenIvanov, Вы писали:

SI>А потом его переписали с помощью идиомы COW.

SI>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.

А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...
Re[3]: О производительности
От: MT-Wizard Украина  
Дата: 27.08.09 15:25
Оценка:
Здравствуйте, Hawk, Вы писали:

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


SI>>А потом его переписали с помощью идиомы COW.

SI>>И тут для всех одновременно наступило счастье, пароксизм, катарсис и все такое.

H>А что такое COW, и где про это почитать? Гугль все больше про домашнюю скотину выдает...


http://en.wikipedia.org/wiki/Copy-on-write
А ти, москалику, вже приїхав (с)
Re[3]: О производительности
От: IID Россия  
Дата: 01.09.09 21:20
Оценка:
Здравствуйте, alexeiz, Вы писали:

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


А почему бы для writeable данных не использовать Read/Write блокировки, вместо эксклюзивных lock/unlock ?
kalsarikännit
Re[3]: О производительности
От: LaPerouse  
Дата: 04.09.09 08:51
Оценка:
Здравствуйте, D. Mon, Вы писали:

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


C>>Ну где же, где примеры наступления счастья от переписывания всего на С++???


DM>Есть обратный пример: переписал транслятор с ICFPC'07 с С++ на Окамл без изменений алгоритма, скорость возросла в 10 раз.


Это прямо-таки удивительно (если без изменений алгоритма).
Социализм — это власть трудящихся и централизованная плановая экономика.
Re: О производительности
От: hexamino http://hexamino.blogspot.com/
Дата: 07.09.09 09:44
Оценка:
Здравствуйте, Sheridan, Вы писали:

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

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

Переход к функциональным иммутабельным структурам данных
Автор: thesz
Дата: 21.02.09
— ускорение 10%
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.