Что вызывает плохую производительность в потребительских приложениях? [закрыто]

Мой Comcast DVR реагирует на каждое нажатие клавиши пульта дистанционного управления не менее чем за три секунды, превращая простую задачу просмотра телевизора в разочаровывающее нажатие на кнопки. Мой iPhone занимает не менее пятнадцати секунд для отображения текстовых сообщений и вылетает cras раз, когда я пытаюсь запустить приложение iPod; простое получение и чтение электронной почты часто занимает больше минуты. Даже navcom в моей машине имеет мягкое и не отвечающее управление, часто глотая последовательные входные данные, если я делаю их с интервалом менее нескольких секунд.

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

Что за этим стоит? Это техническая или социальная проблема? Кто или что несет ответственность?

Это потому, что все они написаны на управляемых языках, а не на собственном коде? Это отдельные программисты, которые написали программное обеспечение для этих устройств? Во всех этих случаях разработчики приложений точно знали, на какую аппаратную платформу они нацелены и каковы ее возможности; они не приняли это во внимание? Это тот парень, который повторяет «оптимизация - корень зла», он сбил их с пути? Было ли это менталитетом «о, это просто дополнительные 100 мсек» каждый раз, пока все эти миллисекунды не складываются в минуты? Это моя вина, что я купил эти продукты?

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

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

Хороший вопрос. То, что я вижу ежедневно, это.

Люди работают над приложениями большого размера. Когда они работают, возникают проблемы с производительностью, как и ошибки. Разница в том, что ошибки «плохие», они кричат ​​«найди меня и исправь меня». Проблемы с производительностью просто сидеть там и ухудшаться. Программисты часто думают: «Ну, у моего кода не будет проблем с производительностью. Скорее, менеджмент должен купить мне более новую / большую / более быструю машину».

Дело в том, что если разработчики периодически просто ищут проблемы с производительностью (что на самом деле очень просто ), они могут просто их устранить.

Вместо этого "состояние техники" является:

1. полагаться на афоризмы, такие как "избегать преждевременной оптимизации" и 90/10 ху-хау.
2. смело говорите о профилировании, а иногда даже пробуйте его, часто с неутешительными результатами, как вы видите во всех SO-вопросах по этому поводу.
3. отступить на старые добрые догадки, замаскированные под опыт и знания.

Но на самом деле это отрицательно. Чтобы быть положительным, этот метод работает почти все время, и он не может быть проще. Вот подробный пример .

Это не техническая проблема, это проблема маркетинга и управления.

Вы можете закатывать глаза в этот момент, но, пожалуйста, потерпите меня.

Компания продает свой «продукт», а люди, которые определяют, что это такое, являются «менеджерами по продукту». В технических фирмах на это влияют многие другие - эксперты по пользовательскому опыту, yadda yadda. Но в конечном счете, менеджеры по продукту несут ответственность за написание спецификаций того, что должен получить пользователь.

Итак, давайте возьмем ваш Comcast DVR. В идеале все должно работать так:

1. Менеджер продукта пишет в спецификации: «Когда пользователь нажимает кнопку на пульте дистанционного управления и находится в пределах 25 футов от цифрового видеорегистратора, цифровой видеорегистратор должен ответить на нажатие в течение 250 миллисекунд».
2. Технические специалисты создают оборудование, пишут встроенное программное обеспечение и т. Д.
3. Тестировщики QA либо утверждают, что система соответствует спецификации, либо возвращают ее технической команде для исправления.

Конечно, многое может пойти не так:

• Менеджер по продукту не может добавить ответ кнопки в спецификации
• QA люди делают посредственную работу по тестированию против спецификации
• Кто-то выбрал технологии, которые не позволяют выполнять спецификацию, поэтому требование наказывается
• Технический персонал не хватает, или кто-то ускорил график, и какой-то менеджер говорит: «Забудьте об отзывчивости - закончите эту другую функцию».
• Менеджер по продукту не публикует требование об отзывчивости до тех пор, пока в игре не будет слишком поздно, оно не может быть выполнено к дате поставки
• Руководство решает не отправлять что-либо на тестирование QA до тех пор, пока ускорение медленного кода не приведет к дестабилизации продукта.

Вы видели всех бездарных программистов там? Там не было ни одного.

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

Но на самом деле, если менеджеры по продукту и сотрудники QA спят за рулем, мы, программисты, не можем восполнить это.

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

Потому что программисты не идеальны.

Я программист встроенных вещей. Часть моего кода не идеальна. Большая часть моего встроенного кода работает быстро.

Исправить проблемы с производительностью в конце проекта очень сложно.

Иногда, чтобы сделать вещи простыми (и, следовательно, тестируемыми, разработанными в реальном времени, без фатальных ошибок), мы размещаем такие вещи, как удаленный ввод, в «службу», которая не является частью основного приложения. Конечный результат, латентность. Альтернатива - поместить все в монолитное приложение - это ошибка с ошибками в C или C ++ (два самых распространенных встроенных языка).

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

Сложность вызывает отставание из-за задержки на многоуровневой обработке. Вы спрашивали о возможностях. Попробуйте действительно старую Nokia, такую ​​как старый 3210. Zippy fast UI. Не так много возможностей.

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

Производительность пользовательского интерфейса должна быть требованием, которое вы проверяете в процессе разработки.

Если он не указан, разработчик привыкнет к нему. Мы все делаем это. "Мой ребенок не уродлив"

И это не языки GC; встроенный в реальном времени Java настолько быстр, что это страшно. (С другой стороны, встроенный Python - тотальная собака)

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

Некоторые DVD-плееры просто запускают сценарий «извлечения» для выполнения извлечения. Ваш DVR, возможно, использовал этот подход, чтобы сохранить расходы на разработку в разумных пределах. Тогда вы экономите на процессоре или оперативной памяти, и это отстой.

Это потому, что все они написаны на управляемых языках, а не на собственном коде?

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

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

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

Во всех этих случаях разработчики приложений точно знали, на какую аппаратную платформу они нацелены и каковы ее возможности; они не приняли это во внимание?

Частично. Для начала, точная аппаратная платформа, вероятно, неизвестна, так как об этом часто договариваются с различными производителями параллельно во время разработки программного обеспечения. Фактически, после первоначального выпуска могут даже быть небольшие (но не обязательно незначительные) изменения в базовом оборудовании. Однако я бы согласился, что общие возможности будут известны.

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

Конечно, это не оправдывает недостаточное тестирование на соответствующем прототипе оборудования перед выпуском. Эта вина, вероятно, лежит вне контроля dev / qa.

Это тот парень, который повторяет «оптимизация - корень зла», он сбил их с пути?

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

Скорее всего, слишком много программистов принимают одну из двух крайностей в отношении оптимизации.

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

Было ли это менталитетом «о, это просто дополнительные 100 мсек» каждый раз, пока все эти миллисекунды не складываются в минуты?

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

Дело в том, что современное компьютерное оборудование (включая встроенные устройства) намного быстрее, чем люди считают. Большинство людей, даже «опытных» программистов, не понимают, насколько быстры компьютеры. 100 мс это долгое время - очень долгое время . И как это происходит, это «очень долгое время» сокращает 2 пути:

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

Это моя вина, что я купил эти продукты?

Да, безусловно. Ну, не вы лично, а потребители в целом. Продукты продаются (и покупаются ) по контрольным спискам функций. Слишком мало потребителей требуют лучшей производительности.

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

Но они не, так что мы не; и каждый год новые мобильные телефоны работают медленнее на более быстром оборудовании.

(Вопросы не заданы.)

• Виноваты ли маркетологи? Частично. Им нужны даты выхода. И когда вырисовывается указанная дата, выбор между «заставить его работать» и «сделать это быстрее» не составляет никакого труда.
• Виноваты ли продавцы? Частично. Они хотят больше функций в контрольном списке. Они раскручивают списки функций и игнорируют производительность. Они (иногда) дают нереальные обещания.
• Виноваты ли менеджеры? Частично. Неопытные менеджеры могут совершать много ошибок, но даже очень опытные менеджеры могут (совершенно справедливо) пожертвовать временем, чтобы решить проблемы производительности в пользу других.
• Виноваты ли спецификации? Частично. Если что-то упущено из спецификации, гораздо легче «забыть» об этом позже. И если конкретно не указано, какова цель? (Хотя я лично считаю, что если команда будет гордиться своей работой, она все равно будет беспокоиться о производительности.)
• Виновато ли образование? Может быть. Образование, вероятно, всегда будет на заднем плане. Я, конечно, не одобряю «образование», которое быстро производит новичков с поверхностным пониманием разработки программного обеспечения. Однако образование, опирающееся на теорию и прививающее культуру обучения, не может быть плохим.
• Виноваты ли обновления? Частично. Новое программное обеспечение, старое оборудование действительно искушает судьбу. Даже до выпуска версии X, X + 1 находится в планировании. Новое программное обеспечение совместимо, но достаточно ли старого оборудования достаточно быстро? Было ли это проверено? Конкретное исправление производительности может быть добавлено в новое программное обеспечение - поощрение необоснованного обновления программного обеспечения

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

Итак, в какой момент все пошло не так для этих продуктов?

ИМХО, мы не можем определить какую-то одну точку. Есть много способствующих факторов, которые развивались с течением времени.

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

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

У меня есть несколько предложений (как технических, так и нетехнических), которые могут помочь:

• На диванах как можно - используйте свой продукт. Нет ничего лучше, чем опыт из первых рук, чтобы выявить неловкие, медленные или неудобные вещи. Однако вам нужно будет сознательно избегать недостатков из-за «инсайдерских знаний». Например, если у вас нет проблем с синхронизацией контактов, потому что вы делаете это с помощью скрипта Python для бэкдора - вы не используете «продукт». Что поднимает следующий вопрос ...
• Слушайте своих пользователей (желательно из первых рук, но по крайней мере из вторых рук через службу поддержки). Я знаю, что программисты (как правило) предпочитают скрываться и избегать взаимодействия с людьми; но это не поможет вам обнаружить проблемы, с которыми сталкиваются другие люди при использовании вашего продукта. Например, вы можете не заметить, что пункты меню медленные, потому что вы знаете все ярлыки и используете их исключительно. Даже если в руководстве полностью документированы все сочетания клавиш, некоторые люди все равно предпочитают меню - несмотря на то, что оно невыносимо медленное.
• Стремитесь постоянно улучшать свои навыки и знания в технике. Развивайте умение критически анализировать все, что вы изучаете. Регулярно переоценивайте свои знания. В некоторых случаях будьте готовы забыть то, что, как вы думали, вы знали. Который воспитывает ...
• Некоторые технологии / методы могут быть очень хитрыми, приводя к тонким недоразумениям и неправильным реализациям. Другие в процессе эволюции общих знаний или доступных инструментов могут оказаться в фаворе или в немилости (например, синглтоны). Некоторые темы настолько хитры, что порождают кучку «фокусных мудрецов», которые распространяют огромное количество дезинформации. Мой особенный багбир - дезинформация о многопоточности. Хорошая многопоточная реализация может значительно улучшить пользовательский опыт. К сожалению, многие дезинформированные подходы к многопоточности значительно снизят производительность, увеличат ошибочные ошибки, увеличат риски взаимоблокировок, усложнят отладку и т. Д. Так что помните: только потому, что «эксперт» сказал это, это не так.
• Стать владельцем. (Не серьезно, я не играю в бинго в зале заседаний.) Ведите переговоры с менеджерами, владельцами продуктов, менеджерами по продажам о функциях производительности, имеющих приоритет над некоторыми элементами контрольного списка. Требуйте лучших спецификаций. Не по-детски, но задавая вопросы, которые заставляют людей задуматься о производительности.
• Быть взыскательным потребителем. Выберите телефон, который имеет меньше функций, но работает быстрее. (Не быстрее процессора, быстрее пользовательского интерфейса.) Тогда похвастаться этим ! Чем больше потребителей начнут требовать производительности, тем больше счетчиков бинов начнут составлять бюджет.

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

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

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

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

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

Если у вас iPhone 3G, Apple выпустила пару обновлений ОС, которые были оптимизированы только для новых устройств. Более поздние обновления ОС для 3G могут обеспечить немного лучшую производительность на 3G.

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

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