Java является действительно медленным?

Как говорит Паскаль, Java находится на уровне других языков высокого уровня. Однако, как кто-то, кто работал с оригинальными JVM на Windows 98 , в то время, когда уровень абстракции, предоставленный виртуальной машиной Java, должен ли мы сказать, болезненный.

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

В середине девяностых годов, когда Java ударил на основной порядок, C ++ был доминирующим языком, и в Интернете все еще были довольно новыми. Кроме того, JVMS и GC были относительно новыми концепциями в развитии основных. Ранние JVMS были вроде медленного (по сравнению с C ++, работающим на голый металл), а также пострадали от иногда длинного сбора мусора, которые привели к репутации Java, будучи медленно.

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

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

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

3. Другим способом, в котором Java является языком высокого уровня, имеется сборка мусора . Сборка мусора может быть медленнее, чем Malloc и и Free для программ, которые выделяют одновременно все необходимые им память и работают с этим. Проблема в языках, у которых нет сборной мусора, программисты, как правило, пишут только программ, которые выделяют всю память, которая им нужна одновременно и отключается, если оно оказывается, какая-то произвольная максимальная константа размера была переполнена. Таким образом, сравнение - яблоки на апельсины. Когда программисты прилагают усилия для записи и отладки программ с динамическими выделением прикованных структур в языках без Gc, они иногда считают, что их программы больше не быстрее, чем на языке GC, потому что Malloc и Бесплатно не бесплатны! У них тоже есть над головой ... плюс, не имея сил ГК, чтобы уточнить, кто освобождает то, что, и необходимость уточнить, кто освобождает, что, в свою очередь, когда-нибудь заставляет вас делать копии - когда несколько функций понадобятся данные, и это не ясно, что будет использоваться его последним - тогда как копирование не было бы необходимости на языке GC.

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

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

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

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

Что касается производительности впоследствии, мои собственные ориентиры на компактных вычислениях с доступом массива (в основном хэш-функциями и другими криптографическими алгоритмами) обычно показывают, что оптимизированный код C составляет около 3x быстрее, чем код Java; Иногда C составляет всего на 30% быстрее, чем Java, иногда C может быть 4 раза быстрее, в зависимости от реализованного алгоритма. Я видел фактор 10x, когда код «C» был фактически сборкой для больших целочисленных арифметики, из-за размножеств размножения 64x64-> 128, которые предлагает процессор, но Java не может использовать, потому что его самый длинный целочисленный тип - 64-битный . Это крайний случай. В соответствии с практическими условиями, входным / выводом и пропускной способностью памяти, предотвращающие CHED Code на самом деле в три раза быстрее, чем Java.

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

Или, возможно, «люди идиоты» - лучший ответ.

Я не сталкивался с этим раньше, но после некоторых исследований кажется, что существует устаревшая поддержка с помощью опции NetFx40 _ LegacySecurityPolicy .

<configuration>
  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true" />
  </runtime>
</configuration>

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

Джошуа Блох (признанный эксперт Java) фактически рекомендует этот подход в его книге Effectife Java 2nd Edition на стр. 17: Обеспечить собственность Singleton с частным конструктор или тип enum.

Это внестроена информация с первых дней (середина до конца 1990-х годов) Java. Каждая основная версия Java представила значительные ускорения по сравнению с предыдущей версией. С Oracle, по-видимому, слияние Jrockit с Sun's JVM для Java 7, эта тенденция выглядит настроен на работу.

По сравнению со многими другими популярными современными языками (Python, Ruby, PHP), Java на самом деле значительно быстрее для большинства применений. Это не совсем совпадает с C или C ++, но для многих задач достаточно близко. Реальные проблемы с производительностью должны быть о том, сколько памяти она заканчивается.

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

1. медленное время запуска в виртуальной машине. Ранняя реализация Java заняла много времени для запуска и загрузки библиотек требуния и приложение по сравнению с собственными приложениями.

2. Медленный интерфейс. Раннее Swing был медленным. Это, вероятно, не помогло, чтобы большинство пользователей Windows нашли уродливую L & F по умолчанию.

Учитывая вышеуказанные пункты, неудивительно, что люди получили «Java - медленное» впечатление.

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

Вы не убедите пользователя, что «он выполняет код очень быстро», когда приложение займет 8 секунд, чтобы начать против его старого приложения Visual Basic, которое начинается сразу - даже если выполнение кода и время запуска вообще не может быть подключено.

Разрушивает первое впечатление - отличный способ начать слухи и мифы. И слухи и мифы трудно убить.

Короче говоря, Java не медленно. Люди, имеющие медленное отношение «Java», основаны на первых впечатлениях от Java более 10 лет назад.

Java имеет репутацию медленного, потому что он был медленным. Первые версии Java либо не имели, либо имели довольно плохую компиляцию Just In Time. Это означало, что код, хотя и байт-код, интерпретировался, поэтому даже для простейших операций (таких как сложение двух целых чисел) машина должна была делать всевозможные сравнения и деривативы указателей и вызовы функций. Компилятор JIT постоянно совершенствуется; Теперь это в точку, где, если я пишу код C++ небрежно и код Java небрежно, Java иногда превосходит C++, потому что компилятор JIT понимает, что у меня есть некоторые ненужные указатели dereferencing и будет заботиться о нем для меня.

Если вы хотите увидеть, насколько велика разница между компиляцией JIT, ознакомьтесь с интерпретируемыми и не интерпретируемыми тестами на Эталонном тесте компьютерных языков . (Pidigits использует внешнюю библиотеку для выполнения всех вычислений, чтобы эталон не менялся; остальные показывают 6-16х ускорение!)

Итак, это основная причина. Есть множество других, меньших причин, которые не помогли делу: изначально время запуска Java было медленным (сейчас исправлено); загрузка веб-приложений на Java занимает много времени (гораздо меньше правды теперь с широко доступным широкополосным доступом и с большими вещами, такими как фильмы); UI Swing не был (и до сих пор не написан) написан с учетом производительности, поэтому он гораздо меньше snappy, чем эквиваленты в, например, C++.

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

Это не помогает, чтобы медленное время загрузки JVM и время загрузки апплета заметно фирмено с кофейной чашкой Java, поэтому люди связывают ждать с Java. Когда Flash занимает много времени для загрузки, брендинг сообщения «Загрузка» указывается разработчиком Flash, поэтому люди не виноваты технологии Flash в целом.

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

Java был медленным, обратно в день. Он стал намного быстрее из-за несколько поколений улучшений производительности . Последний я слышал, это обычно в течение 10% от скорости C # - иногда быстрее, иногда медленнее.

Запуск Applet Java все еще медленно, потому что вы должны начать целый JVM, который должен загрузить все это классы. Немного нравится загрузить другой компьютер. Как только JVM начинается, это довольно быстро, но запуск обычно то, что люди помнят.

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

Молоток намного медленнее от выкатывания теста, чем многие другие инструменты. Не делает молот «медленнее», ни менее полезно для задач, которые она предназначена для того, чтобы сделать.

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

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

Проверьте Трубопровод в F # для пояснения.

(Если вы знакомы с командной строкой unix и такими каналами, как

cat file1 | sort | head 

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

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

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

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

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

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

Кажется, вы задаете два совершенно разных вопроса:

1. Действительно ли Java работает медленно, и если да, то почему?
2. Почему Java воспринимается как медленная, хотя она быстрее многих альтернатив?

Первый из это более или менее вопрос типа "какова длина веревки". Все сводится к вашему определению «медленного». По сравнению с чистым интерпретатором Java чрезвычайно быстра. По сравнению с другими языками, которые (обычно) компилируются в какой-то байт-код, а затем динамически компилируются в машинный код (например, C # или что-то еще в .NET), Java примерно на одном уровне. По сравнению с языками, которые обычно компилируются в чистый машинный код, и в которых (часто большие) команды людей работают только над улучшением своих оптимизаторов (например, C, C ++, Fortran, Ada), Java неплохо справляется с немногими , но в целом имеет тенденцию быть, по крайней мере, несколько медленнее.

Многое из этого связано в первую очередь с реализацией - в основном, это сводится к тому факту, что пользователь ожидает, пока выполняется динамический / JIT-компилятор, поэтому, если у вас нет программы, которая запускается в течение длительного времени для запуска трудно оправдать, что компилятор тратит много времени на сложные оптимизации. Поэтому большинство компиляторов Java (и C # и т. Д.) Не прилагают много усилий для действительно сложной оптимизации. Во многих случаях дело не столько в том, какие оптимизации выполняются, сколько в том, где они применяются. Многие задачи оптимизации являются NP-завершенными, поэтому время, которое они занимают, быстро растет в зависимости от размера атакуемой проблемы. Один из способов сохранить время в рамках разумного - применять оптимизацию только к чему-то вроде одной функции за раз.Когда компилятор ждет только разработчик, вы можете позволить себе потратить намного больше времени и применить ту же оптимизацию к гораздо большим фрагментам программы. Точно так же код для некоторых оптимизаций довольно сложен (и, следовательно, может быть довольно большим). Опять же, поскольку пользователь ожидает, пока этот код загружается (а время запуска JVM часто является существенным фактором в общем времени), реализация должна сбалансировать время, сэкономленное в одном месте и потерянное в другом - и учитывая, как мало кода выгода от сложных оптимизаций, сохранение JVM небольшого размера обычно более выгодно.

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

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

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

Что касается второго вопроса, я думаю, что это во многом вопрос человеческой природы в действии. Некоторые фанатики делают довольно раздутые заявления о том, что Java ослепляюще быстра. Кто-то пробует это и обнаруживает, что даже тривиальная программа запускается за несколько секунд и кажется медленной и неуклюжей, когда все же запускается. Немногие, вероятно, потрудятся анализировать вещи, чтобы понять, что большая часть этого - время запуска JVM и тот факт, что, когда они впервые пробуют что-то, ни один код еще не был скомпилирован - часть кода интерпретируется, а некоторые компилируются, пока ждут. Хуже того, даже когда он работает достаточно быстро, внешний вид обычно будет казаться чуждым и неуклюжим для большинства пользователей, поэтому даже если объективные измерения показывают быстрое время отклика, он все равно будет казаться неуклюжим.

Их сложение приводит к довольно простой и естественной реакции: Java медленная, уродливая и неуклюжая. Учитывая шумиху о том, что это действительно быстро, есть тенденция слишком остро реагировать и делать вывод о том, что он воспринимается как ужасно медленный, а не (точнее) «немного медленнее», и это в основном при определенных обстоятельствах.«Обычно это наихудший вариант для разработчика, пишущего несколько первых программ на этом языке. Выполнение программы« hello world »на большинстве языков происходит мгновенно, но в Java есть легко уловимая пауза при запуске JVM. Даже чистый интерпретатор, который работает намного медленнее в узких циклах, и такой код по-прежнему часто появляется быстрее для такого кода просто потому, что он может загружаться и начинать выполнение немного раньше.

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

Медленность языка во многом зависит от ваших ожиданий "быстрого". Если считать C # быстрым, Java, безусловно, тоже быстрый. Если проблемный домен связан с базами данных или с обработкой в полуреальном времени, Java, безусловно, также достаточно быстр. Если вы рады масштабировать приложение, добавив дополнительное оборудование, Java, скорее всего, будет быстро для вас. Если учесть, что постоянный коэффициент ускорения в масштабе 5-10 не стоит того, вы, скорее всего, считаете Java быстрым.

Если вы выполняете численные вычисления на больших наборах данных или привязаны к среде выполнения, где ресурсы ЦП ограничены, где постоянное ускорение в масштабе 5-10 будет огромным. Даже 0,5 ускорение может означать 500-часовое сокращение времени выполнения вычислений. В этих случаях Java просто не позволяет вам получить последний ярд производительности, и вы, вероятно, считаете Java медленным.

Стефано:

Я был с Java с самого начала, поэтому с моей точки зрения слава быть медленными была создана неадреактивными и медленными графическими интерфейсами (AWT, а затем качается) и в апплетах, вероятно, потому что дополнительного медленного запуска времени ВМ.

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

Java на бэкэнде и вычислительный уровень не так медленно. Colt является одним из лучших примеров:

Последнее устойчивое выброс Colt разбивает барьер 1.9 GFLOP / S на JDK IBM-1.4.1, Redhat 9.0, 2x (скрытый) ГГц.

Существует много вещей, находящихся за пределами основной Java, которая должна быть рассмотрена, как в реальном времени Java или специальные механизмы для повышения скорости, такой как Javolution , а также опережает компиляцию (например, GCJ). Кроме того, есть IC, который может выполнить java Bytecode напрямую, как, например, тот, который находится в нынешних iPhone и iPods ARM Jazelle .

Я думаю, что, как правило, сегодня это политическое решение (например, нет поддержки Java на iPhone / iPod), а решение против Java в качестве языка (потому что многие думают, что это слишком многословно).

Тем не менее, есть много других языков для Java VM в настоящее время (например, Python, Ruby, JavaScript, Groovy, Scala и т. Д.), Что может быть альтернативой.

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

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

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

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

Java определенно медленная, особенно для количественной работы.

Я использую комбинацию R, Python и C/C++ с оптимизированными многопоточными библиотеками ATLAS. На каждом из этих языков я могу выполнить матричное умножение матрицы парных чисел 3000 на 3000 на саму себя примерно за 4 секунды. Используя Colt и Parallel Colt в Java, та же операция занимает 185 секунд! Удивительно, несмотря на то, что эти java-библиотеки являются параллельными по своей природе.

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

Моя машина - HP Core 2 Duo с 3 ГБ оперативной памяти. Я использую 64-битную Ubuntu 10.04 (Lucid Lynx).