Получите текущую операционную систему в Adobe Air

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

Если вы охотитесь на слонов в комнате (в отличие от мышей), вам нужно знать, насколько они велики? НЕТ! Все, что вам нужно сделать, это посмотреть. Именно их величие позволяет легко их найти! Нет необходимости сначала их измерять.

Идея измерения была обычной мудростью, по крайней мере, со времен статьи gprof ( Сьюзен Л. Грэм и др., 1982 ) *, когда все это время находилось прямо у нас под носом. был очень простым и прямым способом найти код, который стоит оптимизировать .

В качестве небольшого примера, вот как это работает. Предположим, вы взяли 5 выборок случайного времени из стека вызовов и случайно увидели конкретную инструкцию на 3 из 5 выборок. Что это говорит вам?

.............   .............   .............   .............   .............
.............   .............   .............   .............   .............
Foo: call Bar   .............   .............   Foo: call Bar   .............
.............   Foo: call Bar   .............   .............   .............
.............   .............   .............   Foo: call Bar   .............
.............   .............   .............   .............   .............
                .............                                   .............

Он говорит вам, что программа тратит 60% своего времени на работу, запрошенную этой инструкцией . Удаление его удаляет эти 60%:

...\...../...   ...\...../...   .............   ...\...../...   .............
....\.../....   ....\.../....   .............   ....\.../....   .............
Foo: \a/l Bar   .....\./.....   .............   Foo: \a/l Bar   .............
......X......   Foo: cXll Bar   .............   ......X......   .............
...../.\.....   ...../.\.....   .............   Foo: /a\l Bar   .............
..../...\....   ..../...\....   .............   ..../...\....   .............
   /     \      .../.....\...                      /     \      .............

Примерно.

Если вы можете удалить инструкцию (или вызвать ее намного реже), это примерно в 2,5 раза быстрее. (Обратите внимание - рекурсия не имеет значения - если слон беременен, он не меньше.) Затем вы можете повторять этот процесс, пока вы действительно не приблизитесь к оптимуму.

• Это не требовало точности измерений, синхронизации функций, подсчета вызовов, графиков, сотен выборок, чего-либо такого типичного для профилирования.

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

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

* Фактически, в этой статье утверждалось, что целью gprof было «помочь пользователю оценить альтернативные реализации абстракций». Он не претендовал на то, чтобы помочь пользователю найти код, требующий альтернативной реализации, на более тонком уровне, чем функции.

Мое второе самое противоречивое мнение - это , или может быть, если бы его не было так трудно понять.