Большинство ошибочных представлений об опасных узких местах

Ответ 1

Без особого порядка:

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

"Penny Wise, Pound Foolish" - думая, что оптимизация - это оптимизация компилятора, суетиться о ++i vs. i++, в то время как горы времени тратятся бесполезно в раздутых проектах, особенно структур данных и баз данных.

"Swat Flies With Bazooka" - настолько очарован самыми причудливыми идеями, которые слышал в классах, что они просто используются для всего, независимо от масштаба.

"Нечеткое мышление о производительности" - выбрасывание таких терминов, как "горячая точка" и "узкое место" и "профайлер" и "измерение", как если бы эти вещи были хорошо поняты и/или уместны. (Бьюсь об заклад, я сбился за это!) Хорошо, по одному за раз:

• hotspot - Какое определение? У меня есть один: это область физических адресов, где регистр ПК обнаруживается значительная часть времени. Это то, что ПК-пробоотборники хороши в поиске. Многие проблемы с производительностью демонстрируют горячие точки, но только в простейших программах проблема в том же месте, что и точка доступа.

• bottleneck - общий термин, используемый для проблем с производительностью, подразумевает ограниченный канал, ограничивающий скорость выполнения работы. Неустановленное предположение состоит в том, что работа необходима. В мои десятилетия настройки производительности я действительно нашел несколько таких проблем - очень немногие. Почти все имеют совсем другой характер. Вместо того, чтобы брать кратчайший маршрут от точки A до B, принимаются небольшие обходные пути в виде вызовов функций, которые требуют мало кода, но не мало времени. Затем эти обходные пути занимают дополнительные вложенные объезды, иногда 30 уровней в глубину. Чем больше обходных путей, тем больше вероятность того, что некоторые из них меньше, чем необходимо, - фактически расточительно - и это почти всегда возникает из-за галопирующей общности - неоспоримого излишества в "абстракции".

• профайлер - универсальная хорошая вещь, не так ли? Все, что вам нужно сделать, это получить профилировщик и сделать профилирование, не так ли? Когда-либо думайте о том, как легко обмануть профайлера, рассказывая вам много чего, когда ваша цель - выяснить, что вам нужно исправить, чтобы получить лучшую производительность? Где-то в вашем дереве звонков, запишите небольшой файл ввода-вывода или небольшой вызов какой-либо системной рутине, или пусть ваш злой близнец сделает это без вашего ведома. В какой-то момент это будет вашей проблемой, и большинство профилографов пропустит это полностью, потому что единственная неэффективность, которую они рассматривают, является алгоритмической неэффективностью. Или, не все ваши подпрограммы будут мало, и они не могут вызывать другую процедуру в небольшом количестве мест, поэтому ваш график вызовов говорит о наличии связи между этими двумя процедурами, но какой вызов? Или предположим, что вы можете понять, что какой-то большой процент времени тратится на путь A называет B называет C. Вы можете посмотреть на это и подумать, что вы не можете с этим поделать, если вы также можете посмотреть на данные, передаваемые в этих звонках вы могли убедиться, что это необходимо. Здесь интересный проект - выберите свой любимый профайлер, а затем посмотрите, как много способов его обмануть. То есть, найдите способы сделать программу более продолжительной, если профилировщик не сможет сказать, что вы сделали, потому что, если вы можете сделать это намеренно, вы также можете сделать это, не намереваясь.

• измеряют (т.е. измеряют время), что профайлеры делали в течение десятилетий, и они гордятся точностью и точностью, с которой они измеряют. Но измерьте, в какое время? и почему с точностью? Помните, что цель состоит в том, чтобы точно определить проблемы производительности, чтобы вы могли плодотворно оптимизировать их, чтобы получить ускорение. Когда вы получаете это ускорение, это то, что есть, независимо от того, как именно вы его оценили заранее. Если эта точность измерения покупается за счет точности местоположения, то вы только что купили яблоки, когда вам нужны были апельсины.

Вот список мифов об эффективности.

Ответ 2

И это то, что происходит, когда один оптимизируется без действительного профиля в руке. Все, что вы делаете без профиля, - это угадать и, вероятно, тратить время и деньги. Я мог бы рассказать о множестве других заблуждений, но многие приходят к тому, что, если этот код не является главным потребителем ресурсов, он, вероятно, прекрасен. Как бы развернуть цикл for, который выполняет ввод/вывод диска...

Ответ 3

• Реляционные базы данных медленны.
• Я умнее оптимизатора.
• Это должно быть оптимизировано.
• Java медленный

И, не связанный:

Некоторые люди, столкнувшись с проблемой, думают: "Я знаю, я буду использовать регулярные выражения". Теперь у них есть две проблемы.

-jwz

Ответ 4

Если я конвертирую всю базу кода в [Insert xxx новейшая технология здесь], это будет намного быстрее.

Ответ 5

"Это должно быть как можно быстрее".

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

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

Ответ 6

• Оптимизация WRONG части кода (люди используют ваш профилировщик!).
• Оптимизатор в моем компиляторе умный, поэтому мне не нужно его помогать.
• Java быстро (LOL)
• Реляционные базы данных бывают быстрыми (ROTFL LOL LMAO)

Ответ 7

Мои правила оптимизации.

• Не оптимизировать
• Не оптимизируйте сейчас.
• Профиль для определения проблемы.
• Оптимизируйте компонент, который занимает не менее 80% времени.
• Найдите оптимизацию, которая в 10 раз быстрее.

Моя лучшая оптимизация уменьшает отчет от 3 дней до 9 минут. Оптимизированный код ускорялся от трех дней до трех минут.

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

Ответ 8

Правила просты:

• Сначала попробуйте использовать стандартные библиотечные функции.
• Попробуйте использовать грубую силу и незнание второго.
• Докажите, что у вас есть проблема, прежде чем пытаться сделать какую-либо оптимизацию.