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

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

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

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

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

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

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

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

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

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

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