Во времена современных вычислений, в «типичных бизнес-приложениях» - почему важна производительность? [закрыто]

Это может показаться странным вопросом для некоторых из вас.

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

Я вижу много разговоров на этом сайте о производительности. Люди часто спорят, какой алгоритм C # будет наиболее эффективным для выполнения задачи, или почему Python работает медленнее, а Java быстрее и т. Д.

Я пытаюсь понять: почему это важно?

Есть определенные области вычислений, в которых я вижу, почему производительность имеет значение: игры, где десятки тысяч вычислений происходят каждую секунду в цикле постоянного обновления, или системы низкого уровня, на которые полагаются другие программы, такие как ОС и ВМ и т. Д.

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

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

Но сегодня у нас есть так много памяти для запасных и компьютеры настолько быстро: это делает на самом деле важно , если конкретный алгоритм Java является O (N ^ 2)? Будет ли это иметь значение для конечных пользователей этого типичного бизнес-приложения?

Когда вы нажимаете кнопку GUI в типичном бизнес-приложении и за кадром оно вызывает алгоритм O (n ^ 2), в наши дни современных вычислений - вы действительно чувствуете неэффективность?

Мой вопрос разделен на две части:

1. На практике сегодня имеет значение производительность в типичной нормальной деловой программе?
2. Если да, пожалуйста, дайте мне реальные примеры мест в таком приложении, где важны производительность и оптимизация.

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

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

• Они часто являются спекулятивными . Я рад видеть, что в Stack Overflow и Programmers.SE профилирование часто упоминается, когда вопрос связан с производительностью, но я также разочарован, когда вижу двух программистов, которые не знают, что профилирование обсуждает о производительности. связанные изменения они должны сделать в своем коде. Они полагают, что изменения сделают все быстрее, но практически каждый раз это не будет иметь видимого эффекта или замедлит работу, в то время как профилировщик указал бы им на другую часть кода, которая может быть легко оптимизирована и которая тратит 80% времени.

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

• Они основаны на субъективных элементах, даже если они связаны с техническими ограничениями. Если вопрос не в том, чтобы чувствовать себя быстрым и отзывчивым, должно быть нефункциональное требование, которое определяет, как быстро должна выполняться операция с конкретными данными, выполняемыми в конкретной системе . На самом деле это происходит примерно так: менеджер говорит, что он находит что-то медленное, а затем разработчики должны выяснить, что это значит. Является ли он медленным, как в «это должно быть меньше 30 мс. В то время как в настоящее время он тратит десять секунд», или медленным, как «мы можем уменьшить продолжительность с десяти до девяти секунд»?

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

Я слышал такие термины, как «профилирование» или «тест», но я не знал, что они означают, и мне было все равно. Более того, я был слишком сосредоточен на чтении книги о Си, и особенно главы, где обсуждались методы оптимизации. Когда я обнаружил, что компьютеры выполняют умножение быстрее, чем деление, я заменил деление умножением везде, где мог. Когда я обнаружил, что вызов метода может быть медленным, я объединил столько методов, сколько мог, как будто предыдущие 100 методов LOC уже не были проблемой.

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

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

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

При этом, производительность в целом важна :

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

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

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

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

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

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

Да, это так!

Поскольку вы просили привести примеры, на ум приходят несколько повседневных ситуаций:

1. Обработка больших данных . Многие бизнес-приложения опираются на базы данных, и во многих случаях эти базы данных переполняются данными. А поскольку дисковое пространство дешевое, количество записанных и сохраненных данных безумно. Буквально на прошлой неделе клиент пожаловался, что его приложение слишком медленное, когда просто отображает некоторые средние числа (запросы на несколько миллионов строк ...). - Также в повседневном использовании мы выполняем преобразования пакетных данных и вычисления со временем выполнения в лиге нескольких ч. В прошлом году алгоритмическая оптимизация позволила сократить время обработки одной партии с 8 до 4 часов, теперь она больше не совпадает с дневной сменой!

2. Отзывчивость : были проведены исследования юзабилити (если у меня будет время, я добавлю ссылки на соответствующие вопросы на ux.se ...), что удовлетворенность пользователей в значительной степени связана с отзывчивостью. Разница во времени отклика 200 мс против 400 мс может легко стоить вам большой процент ваших клиентов, оставляя вас за ваших конкурентов.

3. Встроенные системы : компьютеры не становятся быстрее, они становятся медленнее и меньше ^ _ ^ Разработка мобильных приложений оказывает огромное влияние на разработку приложений. Конечно, мы можем использовать циклы памяти и ЦП, такие как Jelly Beans, на современных настольных компьютерах, но теперь ваш начальник просит вас реализовать алгоритм анализа сна на уродливых часах или на SIM-карте ...

На практике сегодня имеет значение производительность в типичной нормальной деловой программе?

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

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

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

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

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

Это, безусловно, имеет большое значение.

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

Есть три важных заблуждения:

1. Большинство типичных бизнес-компьютеров не "намного мощнее" . Типичный бизнес-компьютер не 8-ядерный i7 с офигенной видеокартой и 16 ГБ оперативной памяти. Это ноутбук с мобильным процессором среднего класса, встроенной графикой, 2 ГБ основной памяти (4 ГБ, если вам повезет), диском 5400 об / мин и корпоративной версией Windows с различными антивирусными программами в реальном времени и политиками, работающими в задний план. Или, для большинства консультантов, «компьютер» - это просто iPhone ...
2. Большинство «типичных бизнес-пользователей» не являются техническими специалистами, они не понимают последствий создания электронной таблицы с 10-12 перекрестными ссылками, 150 столбцами и 30 000 строк (эти цифры не так нереалистичны, как вы можете предположить!), И они тоже не хочу знать. Они просто сделают это.
3. Вторая потеря не стоит - это явно ошибочное предположение.

Моя жена работает в верхней части такой "типичной бизнес-среды". Компьютер, которым она пользуется, стоит примерно 3,5 часа ее рабочего времени. Запуск Microsoft Outlook занимает - в хороший день - около 3 минут, пока он не будет готов (6-8 минут в четвертом квартале, когда серверы находятся под большой нагрузкой). Некоторые из упомянутых таблиц по 30 тыс. Строк занимают 2-3 секунды для обновления значения, во время которого компьютер «зависает» (не говоря уже о том, сколько времени требуется Excel для запуска и открытия их в первую очередь!). Еще хуже при совместном использовании рабочего стола. Даже не заводи меня на SAP.
Безусловно, имеет значение, теряют ли сто тысяч человек по 20-25 минут в течение рабочего дня, ничего не ожидая. Это миллионы потерянныхкоторые вы могли бы вместо того, чтобы потерять их, выплачивать в качестве дивидендов (или платить более высокую заработную плату)
Конечно, большинство сотрудников находятся в нижней части шкалы зарплаты, но даже в более низкое время это деньги .

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

Вы, кажется, недооцениваете, насколько быстро растет N ^ 2. Допустим, у нас есть компьютер, и наш алгоритм N ^ 2 занимает 10 секунд, когда N = 10. По прошествии времени у нас теперь есть новый процессор, который в 6 раз быстрее нашего оригинала, поэтому наше 10-секундное вычисление теперь составляет менее двух секунд. Насколько больше N может быть и все еще вписываться в эти 10-секундные промежутки времени? Теперь мы можем обрабатывать 24 предмета, чуть более чем вдвое. Насколько быстрее должна быть наша система, чтобы обрабатывать в 10 раз больше предметов? Ну, это должно быть в 100 раз быстрее. Данные растут довольно быстро и более чем затрачивают успехи компьютерного оборудования для алгоритмов N ^ 2.

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

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

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

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

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

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

Алгоритм обновления был экспоненциальным, где каждое новое обновление вычислялось вдвое дольше, чем предыдущее ( ). Когда списки попали в диапазон 40 обновлений (* длинных ), потребовалось до 15 минут при полной загрузке, чтобы проверить наличие обновлений. Это эффективно заблокировало многие машины XP во время обновления. Что еще хуже, когда можно было бы пойти , чтобы установить обновления, алгоритм будет работать снова , взяв еще 15 минут. Поскольку на многих машинах установлено автоматическое обновление, это может блокировать машины на 15 минут при каждой загрузке и, возможно, снова с определенной периодичностью.O(n) = 2n

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

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

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

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

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

Есть еще одно определение «хорошей производительности»: оптимизация констант вашего класса сложности. Именно здесь C ++ получает свой титул, где люди начинают медленнее называть Java, где время выполнения на 5% кажется святым Граалем. Используя это определение, вы правы. Компьютерное оборудование со временем усложняется, а компиляторы становятся все лучше и лучше. В какой-то момент вы не можете действительно оптимизировать младший код лучше, чем компилятор - так что просто позвольте ему быть и сконцентрируйтесь на ваших алгоритмах.

На этом этапе использование Java / Haskell / C ++ становится еще одним дизайнерским решением. Сокращение числа может быть сделано через OpenCL на вашем GPU. Пользовательским интерфейсам нужны алгоритмы постоянного времени, и они хороши. Выход и модульность важнее, чем выравнивание ваших классов для 20% лучшего использования кэша. Многопоточность становится важной, потому что люди не хотят быстрого приложения, они хотят адаптивного. Что не важно, так это то, что ваше приложение постоянно на 10% медленнее, чем могло бы быть. Даже 50% - это хорошо (но люди начинают задавать вопросы). Сконцентрируйтесь на правильности, отзывчивости и модульности.

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

Довольно просто: стоимость

У моего предыдущего работодателя была система управления обучением, которая размещалась на физических серверах как модель SaaS. Куча JVM была настроена на 2 ГБ для более старых машин и 3 ГБ для более новых машин, и мы выполнили несколько экземпляров на машину. Вы думаете, этого будет достаточно.

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

Проблема в том, что у нас было 2 ГБ для работы. Таким образом, очевидным решением является начать кэширование всех часто читаемых данных. Потом у нас были проблемы с памятью, начавшиеся прямо перед тем, как я пришел на борт.

Об этом были две школы мысли:

1. Память и аппаратные средства вообще дешевы в наши дни. Просто купите больше оперативной памяти, чтобы вы могли кэшировать больше.
2. Почему системе управления обучением требуется 3 ГБ ОЗУ? Все, что он делает, это выдает SQL-запросы, отправляет перенаправления для запуска курсов и оценивает успеваемость студентов по курсам.

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

Мой нынешний работодатель также размещает систему управления обучением, но размещает ее немного по-другому. Масштабируемость настолько низка, что одна установка (разделенная на 4 виртуальных сервера с балансировкой нагрузки) может обслуживать только 80 клиентов. Некоторые из наших крупных клиентов даже получают собственный набор серверов. Большинство проблем, приводящих к этому, - это проблемы с производительностью, такие как запросы SQL, которые загружают все циклы ЦП, утечки памяти, избыточный код, который делает одно и то же несколько раз. У нас даже есть собственное приложение, единственной целью которого является перезапуск серверов, если они не работают плохо. Есть сотрудник, который поддерживает этот инструмент (наряду с другими обязанностями).

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

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

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

TL; DR

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

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

Это зависит от того, что вы подразумеваете под «типичным» бизнес-приложением. Во многих случаях, особенно в простых CRUD-подобных информационных системах, ответ будет отрицательным. Для этого вам «просто» (иногда это действительно сложно) нужно уметь отслеживать узкие места производительности: я пропустил индекс в своей базе данных? Я посылаю слишком много данных по сети? У меня есть часы за тысячу долларов в моем приложении angular.js? Речь идет о построении звуковой архитектуры, хорошо зная свой технологический стек и избегая бессмысленного. Вы можете достичь этого, если вы хороший мастер, а не обязательно ученый. Еще один способ сказать, что ребята, которые создали оптимизатор запросов Oracle, занимались вопросами алгоритмической сложности, вам просто нужно правильно использовать то, что они вам предоставили.

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

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

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