Для ваших сложных алгоритмов, как вы измеряете его производительность?

Question

Давайте пока предположим, что вы сузили границы типичных узких мест в вашем приложении. Насколько вы знаете, это может быть пакетный процесс, который вы запускаете для переиндексации ваших таблиц; это могут быть запросы SQL, которые выполняются по деревьям с эффективными датами; это может быть сортировка XML нескольких сотен составных объектов. Другими словами, у вас может быть что-то вроде этого:

public Result takeAnAnnoyingLongTime(Input in) {
   // impl of above
}

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

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

Answer 1

Два очка:

1. Остерегайтесь печально известной проблемы «оптимизации холостого хода». (Например, см. Статью по оптимизации под заголовком «Porsche-in-the-parking-lot».) То есть, просто потому, что процедура занимает значительное время (как показано в вашем профилировании) не думайте, что он ответственен за низкую производительность, воспринимаемую пользователем.

2. Наибольший прирост производительности часто достигается не благодаря этой хитрой настройке или оптимизации при реализации алгоритма, а благодаря пониманию того, что алгоритм вообще лучше. Некоторые улучшения относительно очевидны, в то время как другие требуют более детального анализа алгоритмов и, возможно, серьезных изменений в структурах данных. Это может включать обмен времени процессора на время ввода-вывода, и в этом случае вам нужно убедиться, что вы не оптимизируете только одну из этих мер.

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

Answer 2

1. Профиль
2. Найдите верхнюю строку в профилировщике, попытайтесь сделать это быстрее.
3. Профиль
4. Если это сработало, перейдите к 1. Если это не сработало, перейдите к 2.

Answer 3

Как уже упоминалось в этом столбце msdn , настройка производительности сравнивается с работой по покраске моста Золотые Ворота: как только вы закончите рисовать всю вещь, пора вернуться к началу и начать заново.

Answer 4

Я бы измерял их, используя те же инструменты / методы, которые позволили мне найти их в первую очередь.

А именно, привязка времени и регистрация звонков повсюду. Если цифры начинают уменьшаться, значит, вы делаете все правильно.

Answer 5

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

Answer 6

Я бы обозначил две вещи:

1) какая это сложность? Самый простой способ - составить график времени ввода стихов по размеру ввода. 2) как это связано? Это память, или диск, или IPC с другими процессами или машинами, или ..

Теперь пункт (2) легче прояснить и объяснить: многие вещи работают быстрее, если у вас больше оперативной памяти, более быстрая машина или более быстрые диски, или переходите на гигабайт Ethernet или что-то подобное. Если вы заметите свою боль, вы можете положить немного денег на оборудование, чтобы сделать его терпимым.

Answer 7

Это интересный вопрос. Я не думаю, что кто-нибудь знает ответ. Я считаю, что значительная часть проблемы заключается в том, что для более сложных программ никто не может предсказать их сложность. Поэтому, даже если у вас есть результаты профилировщика, очень сложно интерпретировать их с точки зрения изменений, которые необходимо внести в программу, поскольку у вас нет теоретической основы для определения оптимального решения.

Я думаю, что это причина, почему у нас так раздутые программы. Мы оптимизируем только для того, чтобы на наших быстрых машинах работали довольно простые случаи. Но как только вы соберете такие кусочки в большую систему или используете больший входной сигнал, используемые неправильные алгоритмы (которые до этого были невидимы как теоретически, так и практически) начнут показывать их истинную сложность.

Пример: вы создаете строковый класс, который обрабатывает Unicode. Вы используете его где-то, как компьютерная обработка XML, где это действительно не имеет значения. Но обработка Unicode там, принимая участие ресурсов. Сам по себе строковый класс может быть очень быстрым, но вызывать его миллион раз, и программа будет работать медленно.

Я полагаю, что большинство современных программных приложений имеют такую ​​же природу. Есть способ уменьшить его, но это противоречит ООП. Есть интересная книга Есть интересная книга о различных техниках, она ориентирована на память, но большинство из них можно повернуть вспять, чтобы получить большую скорость.