Вы, кажется, задаете два довольно разных вопроса:
- Является ли Java действительно медленной, и если да, то почему?
- Почему 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 запускается. Даже чистый интерпретатор, который работает намного медленнее в тесных циклах и все еще часто будет появляться быстрее для кода, подобного этому, просто потому, что он может быть загружен и начал выполняться немного раньше.