Почему люди до сих пор говорят, что Java работает медленно? [закрыто]

Долгое время в SO и в других местах Java имеет репутацию медленной. От шуток до множества комментариев в вопросах и ответах люди по-прежнему считают, что Java работает медленно, основываясь исключительно на опыте работы с ней в 90-х годах.

Это моя проблема: мы опровергли (большинство) причин, по которым люди считают, что Java работает медленно. Помимо мелочей, Java довольно быстр.

Так почему же люди по-прежнему отказываются верить, что Java сейчас работает быстро? Является ли это частью их мышления, что все, что не является C / C ++, является медленным? Это потому, что люди не проверяют со временем? Это потому, что люди просто предвзяты?

Это приложения. Как вы заметили, мы уже доказали, снова и снова, что в выдуманных сценариев Java код может соответствовать или даже бить производительность так называемых «производительным» языков , таких как C, C ++, Lisp, VB6 или JavaScript. И когда представляются такие доказательства, большинство здравомыслящих, непредубежденных противников будут стыдливо опускать головы и обещать никогда больше не распространять такую ​​клевету.

... но затем они запускают Eclipse, или NetBeans, или Guiffy, или включают поддержку Java в своем браузере, или пытаются запустить приложение на своем любимом телефоне. И они ждут, чтобы это стало отзывчивым ...

... и подожди ...

... и подожди ...



... и подожди ...







... и подожди ...











... и ...




... что я обещал больше никогда не делать ? Извините, должно быть, задремал ...

Этот вопрос работает в ложных посылках: где это имеет значение, Java все еще медленный. Здесь важны алгоритмы, требующие большого объема вычислений для больших наборов данных. Разумеется, их можно оптимизировать, иногда для соответствия коду C / C ++, но только за счет модульности и универсальности. Эффективный код C ++ может быть сконструирован так, чтобы быть универсальным и использоваться в качестве библиотеки общего назначения. Java-код не может. Достаточно взглянуть на сильно оптимизированный Array.sortметод, который использует разные реализации для всех основных типов и чей вариант объекта все еще намного медленнее, чем универсальный C ++, sortпотому что эти объекты должны динамически отправлять сравнения на равенство.

Конечно, как раз во время оптимизаций, выполняемых механизмом HotSpot, можно на самом деле предсказать цель этих виртуальных вызовов и попытаться встроить их. Но это все еще медленнее, чем прямой встроенный вызов, отправляемый внутри sortметода C ++ .

Мой бывший коллега выполнил сравнительные тесты для задачи по огромным наборам данных ( подсчет q- грамм с использованием динамических фигур) с помощью шаблонной реализации C ++ и объектно-ориентированной реализации Java. Код Java был на несколько порядков медленнее, чем код C ++.

Конечно, это сравнение яблок с апельсинами. Но дело в том, что реализация Java была наилучшей возможной реализацией (с точки зрения производительности, учитывая степень модульности, требуемой для библиотеки), как и реализация C ++.

К сожалению, данные бенчмарка не доступны в свободном доступе, но другие нашли похожие цифры при сравнении издержек абстракции во время выполнения. Например, Скотт Мейерс пишет в Effective STL об издержках обобщенной qsortфункции C :

Сортировка C ++ практически всегда смущает qsort C, когда дело касается скорости. […] Во время выполнения sort выполняет встроенные вызовы своей функции сравнения… тогда как qsort вызывает свою функцию сравнения через указатель. […] В моих тестах с вектором из миллиона двойников [сортировка] работала на 670% быстрее…

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

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

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

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

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

Это не имеет никакого отношения к тому, как быстро становится Java. В сознании людей Java является константным идентификатором, связанным со словом «медленный». С этим ничего не поделаешь ни ты, ни Оракул.

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

Я не хочу быть скептиком здесь, но, если Oracle и Google не решат борьбу с Java на хороших условиях, или Google не будет вынужден покупать Java и сделает ее «правильной» платформой с открытым исходным кодом, Java вполне может стать ребенком детская площадка с вшами. То есть никто не захочет трогать его 20-футовым шестом.

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

Одна из причин заключается в том, что люди доверяют тому, что говорят другие, а не тому, что они видят .

Согласно тому, что мне сказали, когда я впервые начал программировать, Java «медленнее», чем C ++, и причина, по которой Java можно использовать, заключается в том, что он «удобен и проще». Считается, что Java приносит безопасность и удобство за счет производительности. Даже когда позже изобрели C #, люди считают, что он быстрее, чем Java, потому что он «родной».

Но истина, которую люди видят, не ощущая этого, заключается в том, что Eclipse, IDE, построенная на Java, является абсолютно БЫСТРОЙ IDE в классе. Я использовал почти все основные потоки IDE, от MS и GNU, Borland ... eclipse - абсолютный король IDE, во многом благодаря его быстроте.

Другая причина - это длительное время запуска .

Java не подходит для разработки крошечного приложения, которое остается в системном трее, потребляет немного памяти, всплывает диалоговое окно, напоминающее вам сделать перерыв; или блокнот, который вы используете, чтобы открыть текстовый файл, прочитать его и закрыть его. Он должен использоваться на чем-то БОЛЬШОМ, например на веб-сервере, который всегда есть, оптимизировать использование вашего вычислительного ресурса, отвечать на миллионы запросов каждый час. Или IDE, как Eclipse, который управляет тысячами файлов рабочей области. Я полагаю, вы не знаете, что ваше Java-приложение работает быстро, пока оно не запустится хотя бы на несколько часов.

@bigown "Почему люди все еще говорят, что Java работает медленно?"

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

Давайте рассмотрим это так, чтобы вы могли видеть правду из того, что я только что сказал выше:

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

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

В-третьих, давайте рассмотрим, для чего нужна основная часть разработки Java: в первую очередь бэкэнд OLTP; Системы мониторинга на втором месте. Любой тип системы предназначен для работы в кластерах и бесперебойной работы в течение нескольких недель, если не месяцев. Значит ли это действительно так, что вашему маленькому приложению-затмению или игрушечному приложению требуется минута-две для загрузки, когда целью РЕАЛЬНЫХ Java-приложений является работа в течение продолжительных периодов времени? Контекст, люди, контекст.

Наконец, основа OLTP в Google и Ebay работает на Java. Я бы воспринял это как доказательство от противного, что Java не медленная (по крайней мере, для условий, которые имеют значение, а не для небольших игрушечных экспериментов, тестов и непроверенных анекдотических доказательств, сделанных специально для того, чтобы сказать: «Х медленный, это отстой».

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

Потому что, можем ли мы закрыть эту тему раз и навсегда?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [прокрутка вниз до таблиц, Java в 3,7-12,6 раза медленнее, чем C ++, исследование сотрудников Google]

PS: Если это не так, назовите мне хотя бы одно быстрое Java-приложение для начала, которое я раньше не видел.

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

Медленный по сравнению с чем? Я думаю о переходе с обычного Ruby на JRuby (Ruby на основе Java), потому что я слышал, что это быстрее.

Мнения - это мнения, а факты - это факты.

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

В прошлых выпусках (2009, 2010, 2011) около 75% программистов, пришедших на финальные раунды, использовали C ++, а не около 15% - Java.

Источник -> http://www.go-hero.net/jam/

Приблизительно в 1997 году я использовал HP Vectra VE (200 МГц) и Windows 95. Большинство приложений работали на этом очень быстро, но затем я попробовал несколько приложений, написанных на Java (IDE, если я правильно помню). Они были очень медленными, по крайней мере, их части с графическим интерфейсом. На их запуск ушло много времени, а элементы графического интерфейса (например, меню) были не очень отзывчивы - визуальные отзывы были задержаны. Кроме того, поскольку приложения Java с графическим интерфейсом имели (имеет) довольно отличительный вид, я научился ассоциировать этот вид (и Java) с низкой производительностью.

Это зависит от того, что вы подразумеваете под медлительностью.

Прежде всего, java as добился большого прогресса в последнее время и в большинстве случаев очень быстр. Но :

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

Кстати, java в некоторых случаях быстрее, чем vanilla C / C ++. Но эти языки дают вам инструменты для их настройки.

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

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

Простой канонический код Java, как правило, соответствует или быстрее, чем простой канонический код C / C ++ / D. Простой канонический код имеет тенденцию выполнять ненужное выделение большого количества памяти, не особенно настраиваться на какую-либо архитектуру ЦП, не иметь тонны низкоуровневых оптимизаций и т.д. быть лучше, чем то, что может сделать статический компилятор.

С другой стороны, если вам действительно нужна производительность и вы хотите что-то настраивать вручную, C / C ++ / D предоставляет гораздо больше возможностей для этого. Вы не можете использовать встроенный ассемблер в Java. Вы не можете использовать уловки грязного типа для обработки чисел с плавающей запятой как массивов битов. Вы не можете использовать пользовательские схемы управления памятью, которые могут быть быстрее, чем GC для вашего конкретного случая использования. Вы не можете выделить столько же в стеке в Java, сколько в C / C ++ / D. В Java единственный способ получить что-то, примерно эквивалентное функциям более высокого порядка, - это интерфейсы и привязка во время выполнения. В D и (я думаю, поправьте меня, если я ошибаюсь) C ++, вы можете передавать функции в шаблоны, что позволяет выполнять связывание во время компиляции без потери гибкости.

Еще одним моментом медлительности Java является 64-битное время выполнения.

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

ЗДЕСЬ есть объяснение, почему 64-битная ВМ запускается медленнее.

Например в Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

Производительность Java очень субъективна, однако, понимание того, почему Java медленная, в значительной степени объясняется причинами, которые отмечают другие: большинство людей воспринимают что-то под влиянием своего более раннего опыта работы с ним, и Java не всегда был хорошо оптимизированным языком. капот. Точно так же vanilla Eclipse не совсем быстрая IDE для работы и меркнет с точки зрения отзывчивости по сравнению с IDE, такой как Visual Studio.

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

В области биоинформатики он используется довольно часто, потому что он хорошо поддерживается и уже существует база для установки, одним из преимуществ которого является то, что вы можете сделать довольно быструю разработку, которую вы не можете сделать с C Если вы посмотрите на языки, используемые для биоинформатики (я лично регулярно использую R, Python и Java), вы заметите, что ни один из них не является самым быстрым, и наборы данных в биоинформатике нередки для 100-х годов. гигабайт информации. В конце концов, человеческое время все еще более ценно, и хотя различия в скорости заметны, размер наборов данных, как правило, достаточно велик, чтобы они все равно работали в одночасье.

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

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

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

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

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

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

которая гласит: вместо отображения списка x с помощью f, а затем отображения его снова с помощью g, требующего двух обходов списка и создания временного списка мусора, просто сопоставьте список с композицией функций.

Это высокоуровневая оптимизация, намного более значимая, чем низкоуровневая производительность Java JVM. Спецификация, которую я дал выше, это не просто красивый синтаксис, это инструкция, написанная пользователем, который говорит компилятору Felix, как выполнять оптимизацию.

Пожалуйста, покажите мне, как делать такие вещи в Java. Нет? Тогда Java работает медленно. Очень медленно. Хаскелл может сделать это автоматически, я верю.

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

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