Содействует ли период времени, когда каждый может попробовать любые идеи, чтобы заставить программное обеспечение работать быстрее?

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

Как создать период времени, когда каждый может попробовать разные идеи для повышения производительности программного обеспечения, над которым мы работаем? Каждый в команде имеет опыт работы с программным обеспечением не менее нескольких месяцев и очень хорош в этом.

Согласны ли вы с тем, что дивергентное мышление поможет найти способы улучшить производительность программного обеспечения? Почему? Почему нет?

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

Наконец, сколько «времени» должно быть выделено для обеспечения хороших результатов без создания возможности ослабления?

Нужно ли экспериментировать, чтобы доказать, что существует «более быстрый способ что-то сделать»? (Добавлено 2011-06-07)

Связанный:

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

( Только для целей вознаграждения -2011/06/07 размер команды составляет 2-4 разработчика, без специального контроля качества. Весь код, модульное тестирование и тестирование производительности выполнены разработчиками. Из-за характера проекта результат профилирования полезен при показе пропорциональное время выполнения, даже если оно не выявило ни одного узкого места.)

Лучше всего определить горячие точки с помощью профилировщика и - как команда - обсудить, как их исправить.

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

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

Программисты, как правило, умны и креативны (так как они необходимы для программирования), поэтому всегда полезно дать им возможность попробовать широкий спектр идей при решении проблем. Однако при попытке повысить производительность важно помнить две вещи (я предполагаю, что под «производительностью» подразумевается снижение скорости выполнения):

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

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

К сожалению, я не могу говорить из опыта. Но я слышал, что у Atlassian есть один день, когда сотрудникам разрешается делать свое дело, что угодно, и представлять свои идеи в какой-то партийной атмосфере. Оказалось, для них это хорошо. Но я должен согласиться с Андерсеном и сказать, что когда дело доходит до производительности, креативные и нестандартные идеи менее важны, чем определение того, какие процессы занимают больше всего времени. Возможно, после того, как вы профилировали свою систему, вы могли бы дать всем один день, чтобы придумать, как помочь ускорить важные разделы процесса. После того, как они представят свои идеи, вы можете выбрать, какие из них попробовать.

Одной из успешных тренировок, которые мы делали в некоторых из моих предыдущих команд, была концепция Deep Dives. Несколько человек собрались в конференц-зале, определили какой-то пользовательский сценарий и просто начали бы либо шагать по коду, либо просматривать журналы профилировщика. В некоторых случаях данные четко показывали узкие места, которые позволяли нам убедить скептиков в том, что в их собственном коде действительно были проблемы с производительностью! Чтобы сделать это успешным, мы придерживались некоторых ключевых принципов:

1. Попытайтесь сосредоточиться на критических сценариях или путях кода, где подозреваются узкие места. Не тратьте время на оптимизацию вещей, которые не нужно оптимизировать (если они не сломаны ...)
2. Держите группу маленькой и сфокусированной на людях, которые знают код лучше всего. Не забудьте включить тестера и менеджера программы в эту функцию - они имеют ключевое представление и могут извлечь выгоду из участия или сбора информации о том, как они могут лучше тестировать.
3. Начните сеанс, попросив владельца области дать диаграмму уровня архитектурного блока высокого уровня и обзор области. Каковы основные компоненты и кратко опишите, что они делают. Вы будете удивлены, сколько раз блок-диаграмма не отражала реальность, когда мы копались в коде. (Фактическая цитата: «Я не знал, что мы все еще использовали этот компонент. Я думал, что мы избавились от этого много лет назад!»)
4. Ожидайте найти функциональные ошибки, а также проблемы с перфорированием. Это хорошая вещь. Кроме того, ожидайте, что иногда вы не найдете ничего значительного. Это тоже может быть хорошо.
5. Ожидайте иметь несколько длинных сессий. Это рабочие встречи. Почувствуйте себя комфортно и работайте через это. Вы можете сделать намного больше, когда вы все можете сотрудничать на длительных отрезках.
6. Делайте заметки, хорошие заметки. Если вы используете базу данных отслеживания дефектов, рассмотрите возможность немедленного открытия проблем, чтобы отслеживать их, даже если они имеют низкий приоритет.

Избегайте участия всей команды в «Performance Push». Обычно они не дают результатов, ожидаемых руководством по причинам, упомянутым Турбьёрном Равном Андерсеном в другом ответе. Вы получите большие выгоды в некоторых областях, регрессии в других областях, где люди не знакомы, и трудно предсказать / отследить, сколько вы должны получить, чтобы сказать «вы сделали». Это сложный разговор с руководством.

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

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

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

2. Не тратьте больше часа на номер 1. Если вы не можете найти проблему в течение часа, используйте профилировщик, чтобы найти нужное место. Как только вы узнаете проблемную точку, вы можете вернуться к номеру 1 и сделать это снова, стараясь найти лучший способ улучшить код, который вы определили.

В общем (**) вы не получите лучшую производительность экспериментальным путем.

Вы получаете это по

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

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

Проверьте этот ответ на ваш другой вопрос.

** Исключением может быть жесткий аппаратно-зависимый код, такой как рендеринг графики, конвейер процессора или поведение CUDA, или эксперименты с сетевыми протоколами или протоколами БД, где вам просто нужно ознакомиться с наилучшим способом его использования.

ДОБАВЛЕНО: Многие программисты больших систем находят нечто удивительное. Дело в том, что в больших идеально сконструированных программах могут быть большие невидимые проблемы с производительностью, и профилировщики не могут их найти, потому что они не локализованы в подпрограммах. Они являются частью общей структуры программы, хотя программа может быть выполнена в самом лучшем стиле.

Просто, чтобы привести конкретный пример, вот программа с исходным кодом (на C ++), которая делает свою работу. Он взят из настоящей программы на Си, над которой я работал.

Он делает то, что должен был сделать, но какая часть его времени на самом деле не нужна? Сколько это можно ускорить?

Что ж, в первой версии программы что-то совершенно разумное и нелокальное (невидимое для профилировщика) занимало 33,3% времени. Когда его заменили, это время было сэкономлено, и это была вторая версия программы.

Во второй версии программы что-то еще (невидимое для любого профилировщика), которое можно было удалить, занимало 16,7% времени. Удаление его привело к версии 3.

В версии 3 13% было удалено. Из того, что осталось, 66% было удалено. Из того, что осталось после этого, 61% был удален!

Затем, наконец, из того, что осталось после этого, 98% было удалено!

Так что же это за картина? Сколько из 1000 циклов, проведенных оригинальной программой, было удалено? 998!

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