Самые опасные заблуждения в отношении узких мест производительности - PullRequest
9 голосов
/ 21 апреля 2010

Парни, которые написали Bespin (облачный редактор кода на основе холста [и более]), недавно рассказали о том, как они повторно анализировали и оптимизировали часть кода Bespin из-за неправильного представления о том, что JavaScript работает медленно. Оказалось, что когда все было сказано и сделано, их оптимизация не принесла существенных улучшений.

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

На какие распространенные заблуждения относительно производительности часто подписываются разработчики?

Ответы [ 8 ]

18 голосов
/ 21 апреля 2010

В произвольном порядке:

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

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

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

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

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

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

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

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

Вот список мифов о производительности.

14 голосов
/ 21 апреля 2010

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

6 голосов
/ 21 апреля 2010

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

6 голосов
/ 21 апреля 2010
  • Реляционные базы данных работают медленно.
  • Я умнее оптимизатора.
  • Это должно быть оптимизировано.
  • Ява медленная

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

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

-jwz

5 голосов
/ 22 апреля 2010

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

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

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

5 голосов
/ 21 апреля 2010
  • Оптимизация НЕПРАВИЛЬНОЙ части кода (люди, используйте ваш профилировщик!).
  • Оптимизатор в моем компиляторе умен, поэтому мне не нужно ничего помогать.
  • Ява быстрая (LOL)
  • Реляционные базы данных работают быстро (ROTFL LOL LMAO)
3 голосов
/ 21 апреля 2010

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

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

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

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

2 голосов
/ 22 апреля 2010

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

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