Действительно ли медленная работа языков программирования - это плохо? [закрыто]

Вот как я это вижу.

Там есть машинный код, и это все, что нужно компьютерам для запуска чего-либо. Компьютеры не заботятся о языках программирования. Для них не имеет значения, является ли машинный код Perl, Python или PHP. Языки программирования не обслуживают компьютеры. Они служат программистам.

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

Итак, действительно ли медленная производительность языков программирования - это плохо?

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

Это всегда компромисс. Для небольших одноразовых задач гораздо быстрее написать сценарий Python, чем приложение C ++, которое делает то же самое (типичным примером для меня будет какая-то пакетная обработка текста или обход дерева каталогов и выполнение каких-либо действий с файлами), и мне все равно, занимает ли это 10 мс или 1000 мс, даже если это в 100 раз медленнее, потому что на написание и тестирование у меня уходит половину времени.

Конечно, было бы неплохо, если бы Python работал так же быстро, как C ++, поэтому в этом смысле я согласен с вашим утверждением, что «slow = bad». Но тогда у меня есть мощный язык, который работает так быстро, как я хочу, не делая некоторых вещей (скажем, проверка границ массивов на необработанных массивах), пока он позволяет мне решить, когда следует сделать этот компромисс (скажем, с помощью std: :вектор).

Довольно просто - медлительность - это плохо

когда программа требует определенного уровня производительности

потому что без этого исполнения вы не выполняете требования.

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

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

ОДНА вещь, к которой стремится компьютер - это быстро. В самом деле! Ножка с картотекой может выполнять ту же работу, что и база данных. Какой-то парень, заводящий печатный станок, может делать то же, что и Apache. Шутки в сторону! И они СДЕЛАЛИ, на самом деле, сотни и сотни лет. Почему компьютер хорош для НИЧЕГО, так это его скорость.

Таким образом, язык программирования, который (по сравнению с другими языками) не в состоянии использовать, в котором отсутствует ЕДИНСТВЕННОЕ преимущество использования компьютеров.

Язык программирования может быть очень высокого уровня, «делать много», все еще быть очень быстрым. OCaml - это язык более высокого уровня, чем PHP, но он генерирует код почти так же быстро, как C. Javascript так же динамичен, как PHP, но он может быть выполнен очень быстро. Так что это в основном проблема с языковой реализацией, а не с дизайном. Динамические языки сложнее реализовать эффективно, но не невозможно.

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

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

Поэтому многое зависит от необходимой вам скорости.

Контекст тоже важен. Загрузка вашей первоначальной конфигурации за 0,5 секунды вместо 0,1 секунды не представляет большой проблемы, но во время выполнения для выполнения запроса вместо 0,1 секунды может потребоваться 0,5 секунды, а не 0,1 секунды. 10.

Просто - клиенты любят быстрое программное обеспечение. На самом деле вся цель компьютеров - это быстрые вычисления.

Медленный относительный. Если у меня есть требование читать порт 10 раз в секунду, язык, который не может создать двоичный файл, который может делать это слишком медленно. Если да, то я пишу веб-приложение, в котором последовательность запросов / ответов между сервером и браузером / клиентом измеряется в секундах, и пользователь, скорее всего, проведет минуты на экране перед нажатием кнопки, языка программирования, который может обрабатывать обработку запроса. в 1 секунду, вероятно, достаточно быстро (большинство, конечно, гораздо быстрее).

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

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

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

Я являюсь частью команды, которая пишет управляющее программное обеспечение для вещательных СМИ. Существует большая вероятность того, что ваш любимый телевизор или радиостанция работает на нем, если вы находитесь в США. Производительность - это одна из вещей, о которой мы чаще всего слышим от клиентов. Первоначально он был написан для небольших операций на одной станции, но теперь мы подписываем крупные вещательные и кабельные сети с сотнями каналов, и масштабирование начинает становиться проблемой. Если мы не сможем заставить их работать быстро, они передадут свои многомиллионные контракты людям, которые могут, и мы останемся без работы. Вот почему мы используем быстрый, скомпилированный язык и оптимизируем наши базы данных.

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

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

Так что скорость на самом деле важна во многих программах. Медленные языки в настоящее время считаются «плохими», потому что они действительно слишком медленные (Python может быть в 50–100 раз медленнее, и это слишком много)

Языки программирования существуют для обслуживания программистов.

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

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

Это тоже глупое заявление. Определите, что вы имеете в виду, используя слово «медленнее» здесь. Медленнее может означать:

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

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

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

Взять хотя бы классический ASP и ASP.net.

Кто-то сказал, что «Клиенты любят программное обеспечение, которое соответствует требованиям и в рамках бюджета». Что ж, это правда - но это имеет отношение к медленному программному обеспечению, и это почти по определению означает более медленные языки программирования (и платформы), алгоритмы и конфигурацию. Медленный язык программирования, возможно, является наиболее важной частью всего вышеперечисленного просто потому, что он является основой, из которой вам будет сложнее всего изменить. Если вы используете БД Oracle и вам нужно больше возможностей, вы можете оптимизировать таблицы / индекс / и т. Д. Легко. Если у вас плохой алгоритм в коде, вы можете написать другой код. Если ваш фреймворк работает медленно, вы можете заменить его - это не так просто, но это выполнимо без переписывания всего. Если ваш язык слишком медленный, вы должны начать практически заново.

Посетите Facebook, чтобы узнать о трудностях, с которыми они столкнулись, чтобы заставить PHP работать достаточно быстро, когда им нужно масштабироваться.

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

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

Много времени было потрачено на то, чтобы программисты как можно быстрее набирали код (а затем все время выполняли модульное тестирование и рефакторинг, смеется). Я обнаружил, что это не такой важный фактор, как думают люди - если вы эксперт в своем языке, вы можете написать его гораздо быстрее, чем если вы неопытны. Таким образом, опытный разработчик C ++ может писать код быстрее и точнее, чем начинающий PHP-разработчик. Поэтому я думаю, что стать экспертом важнее, чем выбрать «легкий» язык, и поэтому мне не нравится культ «переписать в классном, новом материале», который, кажется, повсюду сегодня.

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

Итак, действительно ли медленная производительность языков программирования - это плохо?

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

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

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

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

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