Одним з головних недоліків мови Java традиційно вважається невисока швидкість роботи програм в порівнянні з додатками на мові С ++. І для додатків, де переносимість між платформами або складність розробки не є критично важливою, саме швидкість часто була причиною, по якій розробники робили вибір на користь С ++.
Порівняння продуктивності Java vs. C ++
Порівняно піддавалися програми на С ++, скомпільовані за допомогою G ++ (GCC) 3.3.1, і програми на Java, скомпільовані за допомогою Sun Java 1.4.2_01. Для виконання Java-програм використовувалася віртуальна машина Sun версії 1.4.2_01. Вимірювання велість на ноутбуці з процесором Pentium 4 і 512 Мб пам'яті, який працює під управлінням ОС Red Hat Linux 9 / Fedora Test 1 з ядром версії 2.4.20-20.9 на.
В ході тестування з'ясувалося, що ключовим моментом, що впливає на продуктивність програм на Java є налаштування віртуальної машини. Як видно з діаграми, при використанні "клієнтського" варіанту налаштувань (він встановлений за замовчуванням) практично всі операції програми на Java виконують повільніше, ніж програми на C ++, хоча і не так сильно, як можна було б припустити. Зате при включенні "серверних" налаштувань, в яких немає таких жорстких обмежень по займаному обсягу пам'яті, перевага в більшості тестів виявилося на стороні Java. Причому ряд операцій, наприклад, виклик методу і хешування, виконується в програмах на Java в кілька разів більше, ніж в програмах на C ++. Втім, в основній масі тестів швидкості Java і C ++ виявилися порівнянними, що, звичайно, теж може служити аргументом проти думки про повільну роботу Java.
Результати і дані
Цілковита нісенітниця не бачив ні коли швидкої програми на Java, як серверної так і клієнтської.
2Знатокам. Oracle10g написаний на сях як мінімум, а ось в млість вже в свою Очерет інтегріраванна Java машина ось і вийшло щось на зразок Oracle Aplication Server.
Сам я працюю в тестування вже 3 рік, і поверти мені, мені є з чим порівнювати, тести на продуктивність Java додатків навіть не заявляюсть так як тільки почни так відразу проц в полку лежить :)
розлучення для лохів.
1. статично компілюємо c / c ++ і отримуємо java server method call в швидкісний смітнику
2. тест з постійними кордонами масиву? я тащусь з вас, робята! робимо malloc / new без константних розмірів масивів і припливли. однак перевірка меж масиву.
чувак, ти прищавих школярів розводиш, або на Sun працюєш?
Так ви чого, хлопці, Java-машина
разом зі своїм знаменитим збирачем
сміття пишеться на чому. як мінімум
на С, можливо навіть з використанням класів, а це вже
з ++ (на чому ж їй ще писатися нема на Асмі звичайно ж),
А як С може працювати швидше самого себе.
До того ж якщо використовується компіляцію на льоту,
той час цієї компіляцію чому ніхто не враховує,
порівнюючи виконання програм, написаних на С ++ і жава.
С ++ дає всі можливості для оптимізації, тому що там
все просто і зрозуміло: туди покажчик, сюди покажчик,
якщо не зловживати множинним спадкуванням -все
швидко!
У жаве ж все впирається в
реалізацію конкретної машини (чорний ящик),
тобто в мізки конкретного
програміста, який її писав. Ти можеш думати,
що ти оптімізіруешь а на саміті справі ан, немає!
Машина все виконає за своїм!
Та й потім, запустити повноцінне десктопних програм
на жаве на який-небудь середньої машинці (P 1000, 256мб)
-- ну реально гальмує. Ніякі тести проводити не
потрібно! Особливо ДУІ!
А візьмемо КПК - AWT гальмує безбожно, а про
SWING і говорити не варто!
З усмішкою я читав цю статейку.
Я вважаю, що в проведених тестах є деякі помилки, наприклад, в них вимірюється час виконання програм, а не час виконання однакових операцій. При запуску Java спочатку повинна запуститися віртуальна машина, потім має бути прийнято рішення, чи варто робити компіляцію в нативний код, якщо так, то відбувається компіляція, і тільки після всього цього починає виконуватися алгоритм.
Наприклад, в вичсленіі числа Фібоначчі ми повинні порівняти саме алгоритми обчислення, а все інше не повинно враховуватися.
Ось мої версії програм:
#include
#include
#include
using namespace std;
unsigned long fib (unsigned long n) if (n <2) return(1);
else return fib (n - 2) + fib (n - 1);
>
int main (int argc, char * argv []) int n = ((argc> = 2). atoi (argv [1]). 1);
struct timeval bt, et;
gettimeofday (bt, NULL);
unsigned long f = fib (n);
gettimeofday (et, NULL);
cout <
<<(float)(et.tv_sec-bt.tv_sec+(et.tv_usec-bt.tv_usec)*1e-6)
<
>
import java.util.Date;
public class fibo public static void main (String args []) int n = Integer.parseInt (args [0]);
Date bt = new Date ();
int f = fib (n);
Date et = new Date ();
System.out.println (f);
long dt = et.getTime () - bt.getTime ();
System.out.println ( "Time:" + String.valueOf (dt * 1e-3));
>
public static int fib (int n) if (n <2) return 1;
return fib (n - 2) + fib (n - 1);
>
>
Результат оказалость досить несподіваним:
Duron 750 MHz, 256 MB RAM
ОС: Open SuSe Linux 10
JVM 1.5
1. При прочитанні перекладних статей треба обов'язково дивитися джерело.
Тому як переводять у нас. хмм. Самі перекладачі називають це
"Специфіка новинного перекладу". В даному випадку, заголовок переведений НЕ
повністю, що і викликає бурю емоцій. В оригіналі заголовок говорить
_тільки_ про одне тесті на продуктивність - Unbiased Benchmark.
2. Як говорив aveugle треба придивитися, по яким тестам йшло порівняння.
Дійсно, виклик функції в Java набагато швидше ніж в C ++. так само
як, наприклад, створення об'єкта
3. Для тих, хто вважає Java "інтерпр_і_татором". Це все одно що сказати
що компіляторів C ++ не існує, бо спочатку C ++ перекладається в C і
тільки потім C код компілюються (а це колись було саме так).
Ні Java, ні C # інтерпретацію не використовують, використовується JIT компілятор (програма
компілюється нальоту з байт коду).
Оригінальну статтю дорікнути нема в чому, тести проведені гранично чесно.
До речі, на цю оцінку і можна орієнтуватися. За винятком GUI:
Є кілька серйозних проблем з продуктивністю GUI
- Пам'ять. На кожне Java програма запускається своя віртуальна машина,
біблітекі НЕ расшарівать взагалі (частково проблема вирішена в 5.0).
- Кросплатформеність. За це треба платити, і до 1.4 плата була дуже
велика. З кожною новою версією швидкість роботи збільшується.
- Складальник сміття. Актуально особливо разом з проблемою пам'яті, коли
використовується дискова пам'ять.
З GUI важко говорити про порівняння продуктивності. якщо додати
пам'яті побільше, то різниця невелика. Але якщо пам'яті мало (або
запущено багато додатків) - різниця вкрай істотна.
Залишається додати, що підвищення продуктивності (одна віртуальна
машина на всі Java додатки, расшаріваніє бібліотек, зниження
витрат через платформ, покращення збирача сміття)
одна з головних задач сантехніки на даних момент.
Java давно стала стандартом серверних додатків, збільшивши
свою продуктивність до рівня C ++. Для десктопів Java
як і раніше сильно відстає від С ++.
Хоча терпіти вже можна (за кроссплатформенность, зокрема)
і в майбутньому сподівається є на що.
Счас на моїй машині запущені C ++ Builder JBuilder. (Обидва від Борланда, один написаний на Сі, другий на Яві наскільки я знаю. Яскраві приклади). і чому це цікаво СіБілдер під себе забрав 40 Мб пам'яті, а більш примітивний ДжБілдер 120. та ще й тупить при цьому страшно. )
Все-таки дотримуюся думки, що слід писати Java (джава якщо ламає перемикатися) а не "ява", так як ця назва зарезервовано островом і сортом чаю