Java имеет некоторую степень репутации за медленность.
Современная Java является одним из самых быстрых языков, хотя она по-прежнему является головоломкой памяти. Java имел репутацию медленного, потому что для запуска виртуальной машины потребовалось много времени.
Если вы все еще думаете, что Java медленнее, см. результаты тестов. Тесно оптимизированный код, написанный на скомпилированном языке (C, Fortran и т.д.), Может побить его; однако Java может быть более чем в 10 раз быстрее, чем PHP, Ruby, Python и т.д. Существуют определенные области, где он может бить общие скомпилированные языки (если они используют стандартные библиотеки).
В настоящее время нет оправданий для "медленных" приложений Java. Виноваты разработчики и устаревший код/библиотеки, что намного больше, чем язык. Кроме того, обвиняйте в чем угодно "предприятие".
Библиотеки часто записываются для "правильности" и читаемости, а не для производительности.. По-моему, это основная причина, по которой у Java по-прежнему есть плохая репутация, особенно на стороне сервера. Это делает проблемы String экспоненциально хуже. Некоторые простые ошибки являются общими: объекты часто используются вместо примитивов, снижая производительность и увеличивая использование памяти. Многие библиотеки Java (включая стандартные) будут часто создавать строки, а не повторно использовать изменяемые или более простые форматы (char [] или StringBuffer). Это медленно и создает тонны мусора для сбора позже. Чтобы исправить это, я предлагаю разработчикам использовать, по возможности, примитивные коллекции и особенно библиотеки Javalution.
Операции с строкой немного медленны. Java использует неизменяемые, UTF-16 -кодированные объекты строки, Это означает, что вам нужно больше памяти, больше доступа к памяти, а некоторые операции сложнее, чем с ASCII (C, С++). В то время это было правильное решение для переносимости, но оно сопряжено с небольшими затратами. UTF-8 теперь выглядит лучше.
Доступ к массиву немного медленнее по сравнению с C, из-за проверок границ. Шанс был большим, но теперь он небольшой (Java 7 оптимизирует много лишних проверок).
Отсутствие произвольного доступа к памяти может привести к замедлению обработки ввода-вывода и бит-уровня (например, сжатие/декомпрессия). Это функция безопасности большинства языков высокого уровня.
Java использует LOT больше памяти, чем C,, и если ваше приложение связано с памятью или границей пропускной способности памяти (кэширование и т.д.), это замедляет работу. Flipside заключается в том, что распределение/освобождение быстро растет (сильно оптимизировано). В настоящее время это функция большинства языков высокого уровня и из-за объектов и использования GC, а не для явного распределения памяти. Плюс плохие решения библиотеки.
Входы/выходы на основе потоков медленны из-за (IMO, плохой выбор), чтобы требовать синхронизации при каждом доступе к потоку. NIO исправил это, но это боль в использовании. Можно обойти это, сделав чтение/запись в массив вместо элемента за раз.
Java не предоставляет ту же низкоуровневую функциональность C,, поэтому вы не можете использовать грязные встроенные трюки ассемблера, чтобы сделать некоторые операции быстрее. Это обеспечивает переносимость и является функцией большинства языков высокого уровня.
Общеизвестно, что приложения Java привязаны к очень старым версиям JVM. Особенно на стороне сервера. Эти старые JVM могут быть невероятно неэффективными по сравнению с последними версиями.
В конце концов, Java была разработана для обеспечения безопасности и переносимости за счет некоторой производительности и для некоторых действительно сложных операций, которые она показывает. Большая часть его репутации для медлительности больше не заслуживает.
Распределение и выделение памяти быстро и дешево. Я видел случаи где он составляет 20% FASTER (или больше!) до выделить новый массив с несколькими kB, чем для повторного использования кэшированного.
Объектно-ориентированные объекты и объектно-ориентированные функции быстро растут в использовании(быстрее, чем С++ в некоторых случаях), потому что они разработаны с самого начала. Частично это связано с хорошим GC, а не с явным распределением (что более удобно для множества небольших объектов). Можно кодировать C, который превосходит это (путем катания пользовательского управления памятью и эффективного выполнения malloc), но это непросто.
Вызов метода в основном бесплатный и в некоторых случаях быстрее, чем код с большим кодом. HotSpot использует информацию о выполнении для оптимизации вызовов методов и имеет очень эффективную вставку. Используя дополнительную информацию о выполнении, она иногда может превзойти компиляторы времени и времени (в редких случаях) вручную. Сравните с C/С++, где вызовы методов имеют небольшое ограничение производительности, если компилятор решает не встраивать.
Синхронизация и многопоточность являются легкими и эффективными. Java была разработана с учетом потоков с самого начала, и она показывает. Современные компьютеры обычно имеют несколько ядер, и поскольку потоки встроены в язык, вы можете легко воспользоваться преимуществами. В основном увеличение скорости от 100 до 300% против стандартного однопоточного кода C. Да, тщательно написанные потоки C и библиотеки могут превзойти это, но для работы программиста много работы.
Строки включают длину: некоторые операции быстрее. Это превосходит строки с нулевым разделителем (общие в C). В Java 7 Oracle извлекла оптимизацию String.subString(), потому что люди использовали ее глупо и получая утечки памяти.
Массивная копия сильно оптимизирована. В последних версиях Java использует ручной ассемблер для System.arraycopy. В результате, в операциях с массивами arraycopy/memcopy я видел, как мой код бил эквивалент в C по разумным полям.
JIT-компилятор умеет использовать L1/L2 кеш. Вперед, скомпилированные программы не могут настраивать свой код в режиме реального времени на определенный процессор и систему, в которой они работают. Таким образом, JIT обеспечивает очень эффективные преобразования циклов.
Первоначально Java не был особенно быстрым, но он не слишком медленный. В наши дни Java очень быстро. От людей, с которыми я говорил, что медленная работа Java происходит из двух вещей:
Медленное время запуска VM. Ранняя реализация Java потребовала много времени для запуска и загрузки требуемых библиотек и приложения по сравнению с собственными приложениями.
Медленный интерфейс. Раннее Swing было медленным. Вероятно, это не помогло, что большинство пользователей Windows нашли и по умолчанию Metal L & F уродливым.
Учитывая вышеуказанные моменты, неудивительно, что люди получили медленное впечатление от Java.
Для пользователей или разработчиков, используемых для разработки собственных приложений или даже приложений Visual Basic, эти два пункта являются наиболее заметными в приложении, и это первое впечатление, которое вы получите о приложении (если оно не является графическим приложением, в этом случае применяется только 1.).
Вы не будете убеждать пользователя в том, что "он очень быстро выполняет код", когда приложение занимает 8 секунд, чтобы начать работу с его старым приложением Visual Basic, которое начинается сразу же - даже если выполнение кода и время запуска могут вообще не подключаться.
Разрушение первого впечатления - отличный способ начать слухи и мифы. И слухи и мифы трудно убить.
Короче говоря, Java не медленный. Люди, имеющие "медленное отношение Java", основаны на первых впечатлениях Java более 10 лет назад.
После прочтения страницы, полной комментариев, говорящих, что Java не медленная, мне просто нужно ответить с другим мнением.
Медленность языка во многом зависит от ваших ожиданий за "быстрый". Если вы считаете, что С# будет быстрым, Java тоже быстро работает. Если ваш проблемный домен связан с базами данных или с полу-обработкой в реальном времени, Java тоже достаточно быстр. Если вы счастливы масштабировать свое приложение, добавив больше аппаратного обеспечения, Java, скорее всего, быстро для вас. Если вы считаете, что постоянный коэффициент ускорения в масштабе 5-10 не стоит этого, вы, вероятно, считаете Java быстрым.
Если вы выполняете численное вычисление на больших наборах данных или привязаны к среде исполнения, где ресурсы ЦП ограничены, где постоянное ускорение в масштабе 5-10 будет огромным. Даже 0,5-кратное увеличение может означать 500-часовое сокращение для завершения вычислений. В этих случаях Java просто не позволяет вам получить последний ярлык производительности, и вы, вероятно, считаете, что Java медленная.
Кажется, вы задаете два довольно разных вопроса:
Первый из них - это более или менее вопрос о том, "длинный вопрос". Это сводится к вашему определению "медленный". По сравнению с чистым интерпретатором Java чрезвычайно быстро. По сравнению с другими языками, которые (обычно) скомпилированы в какой-то байт-код, затем динамически компилируются в машинный код (например, С# или что-то еще на .NET). Java примерно соответствует одному. По сравнению с языками, которые обычно скомпилированы с использованием чистого машинного кода, и имеют (часто большие) группы людей, которые ничего не работают, кроме улучшения своих оптимизаторов (например, C, С++, Fortran, Ada). Java довольно хорошо работает по нескольким вещам, но в целом имеет тенденцию быть хотя бы несколько медленнее.
Многие из них связаны главным образом с реализацией - в основном, дело доходит до того, что пользователь ждет, когда выполняется динамический/JIT-компилятор, поэтому, если у вас нет программы, которая запускается довольно долго, чтобы начать с этим трудно оправдать, что компилятор тратит много времени на сложные оптимизации. Поэтому большинство компиляторов Java (и С# и т.д.) Не прикладывают больших усилий к действительно сложной оптимизации. Во многих случаях это меньше о том, какие оптимизации сделаны, чем о том, где они применяются. Многие проблемы оптимизации NP полны, поэтому время, которое они берут, быстро растет с размером атаки. Один из способов удержать время в разумных пределах - это применять оптимизацию только к одной функции за раз. Когда только разработчик ждет компилятор, вы можете позволить себе заняться намного дольше и применять эту же оптимизацию для более крупных фрагментов программы. Аналогично, код для некоторых оптимизаций довольно волосатый (и, следовательно, может быть довольно большим). Опять же, поскольку пользователь ждет, пока этот код загружается (и время запуска JVM часто является значительным фактором в общем времени), реализация должна балансировать время, сохраненное в одном месте, или потерянное в другом - и учитывая, как мало кода выгоды от волосатых оптимизаций, сохранение маленькой JVM обычно более выгодно.
Вторая проблема заключается в том, что с Java вы часто получаете более или менее "один размер подходит всем". Например, для многих разработчиков Java Swing - это, по сути, единственная доступная библиотека окон. В чем-то вроде С++ существуют буквально десятки оконных библиотек, фреймворков приложений и т.д., Каждый из которых имеет свой собственный набор компромиссов между простотой использования и быстрым исполнением, последовательным внешним видом и внешним видом и т.д. Единственным реальным моментом является то, что некоторые (например, Qt) могут быть довольно дорогими (по крайней мере для коммерческого использования).
В-третьих, много кода, написанного на С++ (и C еще более), просто старше и более зрелым. По большому счету он содержит ядро подпрограмм, написанных несколько десятилетий назад, когда проводилось дополнительное время, оптимизируя код, было нормальным, ожидаемым поведением. Это часто дает реальную пользу в коде, который меньше и быстрее. С++ (или C) получает кредит за небольшой и быстрый код, но он действительно намного больше продукта разработчика и ограничений времени написания кода. В какой-то мере это приводит к самоисполняющемуся пророчеству - когда люди заботятся о скорости, они часто выбирают C++, потому что у него есть эта репутация. Они добавляют дополнительное время и усилия в оптимизацию, и записывается новое поколение быстрого кода на С++.
Подводя итог, нормальная реализация Java делает лучшую оптимизацию в лучшем случае проблематичной. Хуже того, где Java видна, такие вещи, как инструментальные средства для окон и время запуска JVM, часто играют большую роль, чем скорость выполнения самого языка в любом случае. Во многих случаях C и С++ также получают кредит за то, что действительно является продуктом просто более усердной работы по оптимизации.
Что касается второго вопроса, я думаю, что это в основном вопрос человеческой природы на работе. Несколько фанатиков делают довольно завышенные требования о том, что Java ослепительно быстро. Кто-то пробует это, и обнаруживает, что даже тривиальная программа занимает несколько секунд, чтобы начать, и чувствует себя медленной и неуклюжей, когда она бежит. Немногие, вероятно, беспокоятся о том, чтобы понять, что многие из них - время запуска JVM, и тот факт, что когда они сначала пытаются разобраться, ни один из кодов не был скомпилирован - часть кода интерпретируется, и некоторые компилируются, пока они ждут. Хуже того, даже когда он работает достаточно быстро, внешний вид и внешний вид обычно кажутся иностранными и неуклюжими для большинства пользователей, поэтому даже если объективные измерения показывают быстрое время отклика, все равно будет казаться неуклюжим.
Добавление их вместе приводит к довольно простой и естественной реакции: Java медленный, уродливый и неуклюжий. Учитывая, что реклама говорит об этом очень быстро, существует тенденция слишком остро реагировать и думать о ней как о довольно медленном, а не о (более точном) "чуть медленнее, и что в основном при определенных обстоятельствах". Это, как правило, в худшем случае для разработчика, написавшего первые несколько программ на этом языке. Выполнение программы "привет мир" на большинстве языков появляется мгновенно, но на Java есть легко воспринимаемая пауза по мере запуска JVM. Даже чистый интерпретатор, который работает намного медленнее на жестких петлях, и такой будет по-прежнему часто появляться быстрее для такого кода, просто потому, что он может загрузиться и начать выполнять бит раньше.
Это устаревшая информация с первых дней (с середины до конца 1990-х годов) Java. Каждая крупная версия Java ввела значительные ускорения по сравнению с предыдущей версией. С Oracle, по-видимому, слияние JRockit с Sun JVM для Java 7, эта тенденция, похоже, будет продолжена.
По сравнению со многими другими популярными современными языками (Python, Ruby, PHP), Java на самом деле значительно быстрее для большинства целей. Это не совсем соответствует C или С++, но для многих задач он достаточно близок. Реальная производительность связана с тем, сколько памяти она использует.
Основным виновником "длительного времени запуска" является динамическое связывание. Приложение Java состоит из скомпилированных классов. Каждый класс ссылается на другие классы (для типов аргументов, вызовы методов...) по имени. JVM должен проверять и сопоставлять эти имена при запуске. Он делает это постепенно, делая только те части, которые ему нужны в любой момент времени, но это все еще некоторая работа.
В приложении C эта фаза связывания происходит в конце компиляции. Он медленный, особенно для больших приложений, но только разработчик видит его. Связывание дает исполняемый файл, который ОС просто нужно загрузить в ОЗУ "как есть".
В Java связывание происходит каждый раз, когда приложение запускается. Следовательно, длительное время запуска.
Были применены различные оптимизации, в том числе методы кэширования, и компьютеры быстрее (и они становятся "быстрее", чем приложения становятся "более крупными" ), поэтому проблема значимости в последнее время значительно сократилась; но старый предрассудок остается.
Как и для производительности, мои собственные тесты на компактных вычислениях с доступом к массиву (в основном хеш-функции и другие криптографические алгоритмы) обычно показывают, что оптимизированный код C примерно в 3 раза быстрее, чем Java-код; иногда C только на 30% быстрее, чем Java, иногда C может быть на 4 раза быстрее, в зависимости от реализованного алгоритма. Я видел 10-процентный коэффициент, когда код "C" был фактически сборкой для большой целочисленной арифметики, из-за кодов операций умножения 64x64- > 128, которые предлагает процессор, но Java не может использоваться, потому что его самый длинный целочисленный тип - это 64-разрядный long. Это краевой случай. В практических условиях соображения пропускной способности ввода-вывода и памяти не позволяют C-коду быть в три раза быстрее, чем Java.
Java определенно медленный, особенно для количественной работы.
Я использую комбинацию R, Python и 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).
Для большинства людей опыт взаимодействия с ним - Java медленный. Мы все видели, что чашка кофе крутится вокруг нашего браузера, прежде чем появится какой-нибудь апплет. Требуется некоторое время, чтобы развернуть JVM и загрузить двоичные файлы апплетов, и это влияет на пользовательский интерфейс так, как это замечено.
Это не помогает, что медленное время загрузки JVM и время загрузки апплета явно заклеймили чашкой кофе Java, поэтому люди связывают ожидание с Java. Когда Flash требуется много времени для загрузки, брендинг сообщения "загрузка" указан разработчиком Flash, t винить технологию Flash в целом.
Все это не имеет ничего общего с производительностью Java на сервере или многими другими способами использования Java за пределами браузера. Но это то, что люди видят, и что не-Java-разработчики помнят, когда думают о Java.
Java имеет репутацию медленного, потому что он медленный. В первых версиях Java была либо нет, либо довольно плохая компиляция Just In Time. Это означало, что код, хотя и байт-код, интерпретировался, поэтому даже для самых простых операций (например, для добавления двух целых чисел) машине приходилось выполнять всевозможные сравнения и вызовы указателей и вызовы функций. Компилятор JIT постоянно совершенствуется; теперь он в точке, где, если я небрежно пишу код С++ и код Java небрежно, Java иногда превосходит С++, потому что компилятор JIT понимает, что у меня есть ненужное разыменование указателя и позаботится об этом для меня.
Если вы хотите увидеть, насколько велика разница в JIT-компиляции, ознакомьтесь с интерпретируемыми или не интерпретируемыми критериями в Компьютерная игра Benchmark Game. (Pidigits использует внешнюю библиотеку для выполнения всех вычислений, так что эталонный тест не изменяется, остальные показывают ускорение в 6-16 раз!)
Итак, это главная причина. Существует множество других, меньших причин, которые не помогли: изначально время запуска Java было медленным (теперь исправлено); веб-приложения на Java требуют много времени для загрузки (что гораздо менее верно теперь с широко доступной широкополосной сетью и с большими вещами, такими как ожидаемые фильмы); UI Swing не был (и все еще не написан) с учетом производительности, поэтому он намного менее мгновенен, чем эквиваленты, например. С++.
Java медленно, назад назад. Это стало намного быстрее благодаря нескольким поколениям улучшений производительности. Последнее, что я слышал, обычно составляет 10% от скорости С# - иногда быстрее, иногда медленнее.
Запуск Java-апплета все еще медленный, потому что вам нужно запустить целую JVM, которая должна загружать все классы. Совсем как загрузка другого компьютера. Как только JVM запускается, он довольно быстр, но запуск обычно является тем, что люди помнят.
Кроме того, есть по крайней мере несколько человек, которые никогда не верят в жизнеспособность Java.
Stefano:
Я был с Java с самого начала, поэтому с моей точки зрения слава медленности была создана невосприимчивыми и медленными интерфейсами GUI (AWT, а затем Swing) и в апплетах, вероятно, из-за дополнительного медленного запуска времени виртуальных машин.
Java предусмотрела и продвинула много исследований в области VM, и были некоторые улучшения, в том числе сбор мусора (вы можете настраивать множество вещей на самом деле, однако часто я вижу системы, в которых используются только значения по умолчанию ) и оптимизацию "горячей точки" (которая в начале и, вероятно, все еще более эффективна на стороне сервера).
Java на бэкэнд и вычислительном уровне не так уж медленный. Colt - один из лучших примеров:
Последний стабильный выпуск Colt разрушает барьер 1.9 Gflop/s на JDK ibm-1.4.1, RedHat 9.0, 2x IntelXeon @2,8 ГГц.
Есть много вещей вне основного языка Java, которые следует учитывать, например, Realtime Java или специальные механизмы для повышения скорости, например Javolution, так как а также компиляцию Ahead-Of-Time (например, gcj). Кроме того, есть IC, который может выполнять Java Bytecode напрямую, например, тот, который находится в текущих iPhone и iPod. ARM Jazelle.
Я думаю, что в целом сегодня это политическое решение (например, поддержка Java на iPhone/iPod) и решение против Java как языка (потому что многие считают, что это слишком многословно).
Однако в настоящее время существует много других языков для Java VM (например, Python, Ruby, JavaScript, Groovy, Scala и т.д.), которые могут быть альтернативой.
Лично я по-прежнему наслаждаюсь им как гибкой и надежной платформой, с отличной оснасткой и доступностью библиотеки, что позволяет работать со всем, начиная от самого маленького устройства (например, JavaCard) до крупнейших серверов.
Молот намного медленнее выкатывает тесто, чем многие другие инструменты. Не делает молоток "медленнее" и не менее полезен для задач, которые он предназначен для выполнения.
Как общий язык программирования, Java находится на одном уровне со многими (если не большинством) для широкого круга задач программирования. Существуют конкретные, тривиальные тесты, для которых Java не будет превосходить решения с ручным кодированием в менее сложных языках, которые "ближе к металлу".
Но когда дело доходит до "приложений реального мира", Java часто является правильным инструментом. Теперь, сказав это, ничто не остановит разработчиков делать медленное решение с помощью ЛЮБОГО инструмента. Неправильное использование инструмента - хорошо известная проблема (просто посмотрите на репутацию PHP и VB). Однако Java (в основном) чистый дизайн и синтаксис делают многое, чтобы уменьшить злоупотребление.
Java - это высокоуровневый язык, и его репутация в настоящее время заключается в обеспечении производительности наравне с другими сопоставимыми языками высокого уровня.
Он имеет динамическое связывание семантики. По сравнению с С++, где не виртуальные методы скомпилированы как вызовы функций, даже лучший компилятор Java в мире должен производить код, который менее эффективен. Но это также более чистая, более высокоуровневая семантика.
Я не помню подробностей, но в первые дни Java я слышал, что на каждый объект Java был обнаружен мьютекс, который должен быть получен и выпущен каждым методом. Это, как правило, делает его лучше адаптированным к concurrency, хотя, к сожалению, только мьютекс на объект не защитит вас от рас или тупиков или любых плохих вещей, которые могут произойти в параллельных программах. Эта часть, если это правда, немного наивна, но она исходила из благих намерений. Не стесняйтесь заполнять меня подробностями, если вы знаете больше об этом аспекте.
Другой способ, которым Java является языком высокого уровня, - это Garbage-Collection. Сбор мусора может быть медленнее, чем malloc и free для программ, которые сразу выделяют всю необходимую им память и работают с ней. Проблема заключается в том, что на языках, не имеющих Garbage-Collection, программисты склонны писать программы только, которые выделяют всю память, которая им нужна, и терпят неудачу, если оказывается, что какая-то произвольная максимальная постоянная размера была переполнена, Таким образом, сравнение - это яблоки для апельсинов. Когда программисты прилагают усилия для написания и отладки программ с динамическим распределением цепочечных структур на языках, отличных от GC, иногда они обнаруживают, что их программы уже не быстрее, чем на языке GC, потому что malloc и free не являются бесплатными! У них тоже есть накладные расходы... Плюс, не имея сил ГК, чтобы указать, кто это освобождает, и указывая, кто освобождает то, что в свою очередь заставляет вас делать копии - когда несколько функций понадобятся данным, и это не ясно, какие будет использовать его последним - тогда как копирование не было бы необходимым на языке GC.
В середине 90-х годов, когда Java попала в основное русло, С++ был доминирующим языком, а сеть все еще была довольно новой. Кроме того, JVM и GC были относительно новыми концепциями в основном развитии. Ранние JVM были медленными (по сравнению с С++, работающими на голом металле), а также страдали от иногда длинных пауз для сбора мусора, что приводило к низкой репутацией Java.
Как говорит Паскаль, Java находится на одном уровне с другими языками высокого уровня. Однако, как и тот, кто работал с оригинальными JVM на Windows 98, на тот момент, когда уровень абстракции, предоставляемый виртуальной машиной Java, будем говорить, больно.
В принципе, это была эмуляция программного обеспечения с небольшой оптимизацией или без нее, которую мы считаем само собой разумеющимся сегодня в JVM.
Многие настольные приложения Java (в такие моменты: Eclipse) плохо реагируют на графический интерфейс, возможно, из-за большого потребления памяти и того факта, что загрузчик классов может делать много ввода-вывода. Это улучшалось, но было хуже несколько лет назад.
Многие (большинство) людей любят делать обобщения, поэтому говорят, что "Java медленный", потому что они воспринимают приложения медленными, когда они взаимодействуют с ними.
Основная проблема с java-приложениями заключается в том, что она огромна из-за большого размера библиотеки исполняемых файлов. Огромные программы много заполняют память и имеют тенденцию к обмену, то есть они становятся медленными.
Причина, по которой Sun JVM велика, заключается в том, что она имеет очень хороший интерпретатор байтового кода, который работает, отслеживая множество вещей. Это означает много данных, что означает память.
Вы можете посмотреть виртуальную машину jamvm, которая является достаточно быстрым интерпретатором (без собственного кода) и очень мала. Он даже быстро запускается.
Люди обычно выходят из строки "это интерпретируется". Потому что когда-то это было, и плохая пресса была передана людьми, которые сбрасывали Java как "слишком медленные" и никогда не возвращались для тестирования более новых версий.
Или, может быть, "люди - идиоты" - лучший ответ.
Я думаю, что когда-нибудь, может быть, не в ближайшем будущем, JIT-компилированные языки будут превосходить скомпилированные языки в любом аспекте (ну, может быть, не время загрузки/потребление памяти) из-за того, что JIT-компиляторы могут делать тяжелые использование поведения во время выполнения и платформы, на которой они работают.