Чому люди все ще кажуть, що 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 ++.

На жаль, дані базових показників не є у вільному доступі, але інші знайшли подібні цифри при порівнянні накладних витрат абстракції. Наприклад, Скотт Майєрс пише в Ефективній STL про накладні витрати на загальну qsortфункцію C :

Сорт C ++ практично завжди бентежить qsort C, коли мова йде про швидкість. […] Під час виконання сортування здійснює вбудовані виклики до своєї функції порівняння ... в той час як qsort викликає свою функцію порівняння через покажчик. […] У моїх тестах на вектор мільйона пар, [сорт] підбіг на 670% швидше ...

Тому що це повільно ... в деяких додатках. Настільні програми повинні реагувати з самого початку, а накладні витрати вважаються повільними.

З іншого боку, якщо ви запускаєте сервер, це не має значення, чи є нагрівання (JIT-аналіз та компіляція) - ви робите це один раз у синій місяць, так що більшість часу це не можна вважати цілком повільним.

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

Треба визнати, у мене склалося враження, що Java повільна, і так, це було з мого попереднього впливу на неї. Зараз я перейшов на різні мови і з того часу зазнав надзвичайно обмеженого впливу на Java. Отже, моя думка не сильно змінилася.

Тому що потрібно покоління, щоб змінити уявлення людей про продукт

Це не має нічого спільного з тим, як швидко стає Java. У свідомості людей Java - це ідентифікатор const, пов'язаний зі словом 'повільно'. Мало що, ви ні з цим, ні з Oracle не можете зробити.

Будьте щасливі, що Oracle ще не знищив культуру програмування Java, роблячи щось необдумане чи дурне . Як і стягнення надмірних витрат на ліцензування для його використання. Або позов на людей на основі патентів на програмне забезпечення, які раніше належали Sun. :: зітхання ::

Я ненавиджу бути найсайєром тут, але, якщо Oracle і Google не вирішать боротьбу з Java на добрих умовах, або Google змушений купувати Java і не робить її "належною" платформою з відкритим кодом, Java цілком може стати дитиною на майданчик, на якому є воші. IE, ніхто не захоче торкатися до нього 20-футовим стовпом.

Примітка. Просто для того, щоб бути зрозумілим, коли я кажу, що покоління, я говорю в людях, а не на комп'ютерних термінах. Тобто, поки люди, які володіють цим сприйняттям, не помруть від старості або заміняться молодим поколінням, сприйняття збережеться. Подумайте в термінах 5 десятиліть, а не 5 років.

Одна з причин - люди довіряють тому, що говорять інші, а не тому, що вони бачать .

Згідно з тим, що мені сказали, коли я вперше розпочав програмування, Java "повільніше", ніж C ++, і причиною, через яку можна було використовувати Java, є те, що це "зручно і простіше". Дуже часто вважається, що Java забезпечує безпеку та зручність за рахунок продуктивності. Навіть коли винайдено пізніше C #, люди вважають, що це швидше, ніж Java, тому що він "рідний".

Але правда, яку люди бачать, не відчуваючи цього, полягає в тому, що затемнення, IDE, побудований з Java, є абсолютно НАЙБІШНИМ ІДЕ в класі. Я використав майже всі основні IDE потоку, ті з MS та GNU, Borland ..., eclipse - це абсолютний король IDE, багато в чому через це швидко.

Ще одна причина - довгий час запуску .

Java не підходить для розробки крихітного додатка, який залишається в системному треї, забирає небагато пам’яті, відкриває діалогове вікно, що нагадує зробити перерву; або блокнот, який ви використовуєте, щоб відкрити текстовий файл, прочитати його та закрити. Його слід використовувати на чомусь великому, наприклад, на веб-сервері, який завжди є, оптимізувати використання обчислювального ресурсу, відповідати на мільйони запитів щогодини. Або IDE, як затемнення, яке управляє тисячами файлів робочої області. Ви не знаєте, що програма Java швидка, доки вона не працює протягом принаймні декількох годин.

@bigown "Чому люди все ще кажуть, що Java повільна?"

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

Давайте знехтуємо цим, щоб ви могли бачити правду сказаного вище:

По-перше, що повільно, в якому контексті, для чого, за яких умов, з якою інженерною / науковою / діловою метою (якщо сказати, що це смокче, це не одна з них). X, або просто "X є Y", де Y - це певний тип негативного твердження, без відповіді на жодне з вищезазначених питань слід бути відхиленим як дурень. Такі заяви не мають місця в техніці. У політичних та юнацьких чатах, можливо, але не на техніці.

По-друге, більшість цих оманливих дурнів плачуть про те, що Ява повільна, тому що ZOMG, їх затемнення вічно запускається (гей, завантажте річ усіма плагінами і здогадайтесь, що відбувається.) Більшість цих дурнів навіть не знають, як щоб настроїти jvm для eclipse для швидкої роботи (або для будь-якої програми Java з цього питання). Тобто вони не мають поняття про налаштування продуктивності, що є реальністю не тільки для Java, але й для будь-якої нетривіальної системи, будь то апаратне чи програмне забезпечення. Отож, саме там вони обеззброюються для будь-якої технічної обґрунтованості при здійсненні таких безглуздих заяв.

По-третє, давайте розглянемо, для чого основна частина розробки Java: насамперед задній OLTP; системи моніторингу, що надходять на друге місце. Будь-який тип системи призначений для роботи в кластерах і працювати безперебійно протягом тижнів, якщо не місяців. Невже тоді важливо, щоб ваш маленький додаток для затемнення або іграшки завантажувався хвилину-дві, коли мета РЕАЛЬНИХ додатків Java - запускатися протягом тривалого періоду часу? Контекст, люди, контекст.

Нарешті, основи OLTP в Google та Ebay працюють на Java. Я б вважав це суперечливим доказом того, що Java не повільна (принаймні, для важливих умов, не для маленьких експериментів з іграшками, орієнтирів та неперевірених анекдотичних доказів, зроблених спеціально для того, щоб сказати, "що X повільно, це смокче".

Є інженерія, і є фанбоїзм. Відгадайте, до якої категорії висловлювань належать такі?

Тому що це, чи можемо ми закрити цю тему раз і назавжди?

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

PS: Якщо це не так, назвіть мені для початку принаймні одне спритневе додаток Java, якого раніше не бачили.

TMHO, це через час, необхідний для запуску VM у браузері. Якщо програма запускається повільно, люди пам’ятатимуть це лише. Тому що довгий час початку справді дратує. Дійсно. Один мій колега сказав мені, що він не використовує Firefox, оскільки це занадто повільно. (?!?). Але, так, гаразд, у Windows, Firefox потребує величезної кількості часу, щоб відобразитися. За його словами, це додаток повільний, він зробив свою думку про загальну швидкість його.

Повільне порівняно з чим? Я думаю про перехід від звичайного Ruby до JRuby (рубін на базі 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, якщо я правильно пам'ятаю). Вони були дуже повільними, принаймні, частинами GUI. Запускати їх було потрібно багато часу, а елементи графічного інтерфейсу (наприклад, меню) не надто реагували - у візуальній зворотній зв’язку були затримки. Крім того, оскільки додатки Java GUI мали (має) досить характерний вигляд, я навчився асоціювати цей зовнішній вигляд (і Java) з низькою продуктивністю.

Це залежить від того, що ви маєте на увазі як повільний.

Перш за все, Java, як і раніше, досягла багатьох успіхів і в більшості випадків дуже швидка. Але:

• Java запускається повільно, тому що вам доведеться завантажувати JVM, перш ніж робити що-небудь.
• Деякі функції безпеки можуть вбивати виступи в деяких випадках. Примірник перевірки з випадковим доступом є прикладом.
• Зробити щось по-справжньому швидко в Java потрібно, щоб попрацювати проти JVM (скористатися лінією кеш-пам'яті для зразка).
• Відсутність метапрограмування передбачає штраф за час виконання з кожною абстракцією, тому продуктивність приходить до вартості дизайну у багатьох випадках.
• Java навряд чи може забезпечити обмеження в реальному часі - за допомогою дизайну - і це може вважатись «повільним» деякими людьми.

До речі, java в деяких випадках швидше, ніж ванільний C / C ++. Але мови мов дають вам інструменти для їх виправлення.

Java - мова програмування, спрямована на продуктивність. Зараз це досить швидко для більшості програм, але для деяких інших недостатньо.

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

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

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

Ще один момент для "повільності" Java - це 64-бітний час виконання.

Я чув, як деякі люди скаржаться, що Java дуже повільна для них на 64-бітних комп’ютерах. Як виявляється, 64-бітний режим виконання Java використовує сервер JVM, який збирає всю програму перед запуском.

ТУТ пояснюється, чому 64-бітний VM запускається повільніше.

Наприклад у 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 не завжди була добре оптимізованою мовою. капюшон. Крім того, Eclipse vanilla - це не дуже швидкий IDE, з яким можна працювати і зникає з точки зору чутливості в порівнянні з IDE, як Visual Studio.

Однак це стосується проблем із інтерфейсом, які виникає у Java при запуску, для більшості програм це досить швидко. Якщо ви шукаєте, ви можете знайти статті, які порівнюють його з іншими мовами, і більшість представлених результатів ставлять їх у діапазон, де це буде проблемою лише тоді, коли ви маєте справу з основними наборами даних.

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

Якби було легше написати швидкий інтерфейс на Java, то це зовсім так, що сприйняття швидкості впаде з радару, оскільки більшість людей не нагнітають мов, що швидкість справді є проблемою щодня.

Для того, щоб кинути в нікчемну монету, я вважаю, що у веб-сайтів Java, як правило, тривалий час запуску та реакції, коли мені здається, що Python або Ruby могли б зробити краще.

Я використовую Eclipse для більшості моїх програмувань, і я повинен сказати, що Java так само швидко, як і все інше, якщо не швидше працює локально і "автономно".

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

Наведу простий приклад. Існує проста оптимізація, яка застосовується при зіставленні списку двічі, яка називається вирубкою лісів: ось для неї написане моєю мовою Felix:

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 повільна. Дуже повільно. [Haskell може зробити це автоматично автоматично, я вважаю].

І перш ніж ви скажете "але Java є мовою OO, така оптимізація не застосовується" .. ну це точно моя думка. Java смокче, і бути OO - одна з головних причин.

Оптимізація JIT ніколи не може бути близькою до конкуренції з тими оптимізаціями, які може зробити гідний компілятор.