QuasarДаже система построенная на DCOM с использованием 3х звенной архитектуры будет менее требовательна к железу, чем аналогичная система, написанная на Яве.
NotGonnaGetUs , скажите честно, это неправда?
Не пользовался DCOM, судить не могу.
Даже если предположить, что это правда, о чём это скажет?
Помимо требований к железу есть и другие факторы, которые могут играть роль при разработке той или иной системы.
Quasar
Но вы скажете, что мол, на яве мы имеем переносимость. Но тем не менее не всегда с первого раза система написанная на Java, скажем под win32 запуститься на том же линуксом или фрей.
Сколько не пишу, почему-то всё запускается с первого раза. Разница между платформами появляется только в виде необходимости подджерживать различные типы веб-браузеров. Всё потому, что количество pure java библиотек равно 99%. Оставшийся 1% используется только там, где в этом есть нужда, а если есть такая нужда, то какие могут быть вопросы о переносимости?!
Quasar
Я не пытаюсь расжечь флейм, просто смотрим на вещи как есть.
Посмотрите статью, кстате:
http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html
Ты правда считаешь, что это статья отражает реальность?
1. Время затрачиваемое на Start up JVM не должно учитываться в тесте, т.к. с ростом сложности приложения оно становится 0, а для тривиальных тестов составляет больше 50% (start up связан с процессом верификации классов подгружаемых JVM, поэтому сравнивать время загрузки пустого класса, как это сделано в тесте - глупо).
С момента написания статьи появилась возможность запустить один инстанс JVM per PC, т.о. о start up overhead'е можно не задумываться.
2. Есть представление о том, что такое Hot Spot и с какой версии java он появился?
Если JVM делает предположение, что данный фрагмент кода будет вызываться часто, этот фрагмент компилируется и далее вызывается native код.
Как это связано с мега тестами?
На момент вызова теста у JVM ещё нет статистики, достаточной чтобы решить нужно его компилить или нет. Т.к. вызов метода-теста происходит один раз, то он будет интерпретироваться, и производительность будет не высока.
С 6-ой версии будет работать такая фича, как переключение с режима интерпретации на native код в процессе _интерперетации_. Т.е. если метод очень долго работает (тест), то не дожидаясь окончания его работы JVM передаст управление native коду.
JVM сделана так, чтобы обеспечить повышенный перфоманс для долго работающих приложений (долго = методы вызываются чаще, чем 1 раз за срок жизни приложения). Одноразовые запуски - удел скриптов.
3. Код в тестах писался так, чтобы нагрузить GC у Java и показать оптимизации для встроенных типов питона.
Hint(1): создание объектов оболочек для каждого int.
Hint(2): преобразование в объекта в String перед печатью.
Hint(3): использование синхронизированных классов
//ConsoleTest
Тест ни о чём.
System.out.println сбрасывает output буффер.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
public class ConsoleTest {
public static void main(String[] args) {
long time = System.currentTimeMillis();
StringBuffer sb = new StringBuffer();
for ( int i = 0 ; i < 1000000 ; i++) {
sb.append(i).append('\n');
}
System.out.print(sb);
System.out.println("time: " + (System.currentTimeMillis() - time));
}
}
^^^ тест с сайта работает у меня 110с, исправленный 10с.
Процесс заключённый в цикле требует всего 0.3с.
Если output перенаправить в файл, а не в консоль моей IDE, то получается 0.6 секунд.
Сравни с сайтом.
Как думаешь, 110с и 0.6с это одно и тоже?
//Hashset
Test c сайта у меня работает 0.26с.
Мой вариант (java 1.5): 0.16с.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
class HashTest {
public static void main(String[] args) {
long time = System.currentTimeMillis();
for ( int i = 0 ; i < 1000 ; i++) {
HashMap<Integer,Integer> x = new HashMap<Integer, Integer>();
for ( int j = 0 ; j < 1000 ; j++) {
x.put(i, j);
x.get(i);
}
}
System.out.println("time: "+ (System.currentTimeMillis() - time));
}
}
Добавь к этому, что 1.1.х работает существенно медленее, чем 1.5 и тогда получится что ни о каких 2х в пользу питона речи быть не может.
К тому же надо понимать, что в данном случае hashMap может быть заменнён на больее подходящую структуру данных, если мы собираемя в ней хранить только числа.
Опять не тест.
//IOTest
Опять не буферезированный output.
Вариант с сайта 0.66с.
Мой вариант 0.43с.
1.2х в пользу питона перекрыт.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
public static void main(String[] args) {
long time = System.currentTimeMillis();
try {
File f = new File("scratch");
PrintWriter ps = new PrintWriter( new BufferedWriter( new OutputStreamWriter( new FileOutputStream(f))));
for ( int i = 0 ; i < 1000000 ; i++) {
ps.print(String.valueOf(i));
}
ps.close();
}
catch (IOException ioe) {
ioe.printStackTrace();
}
System.out.println("time: " + (System.currentTimeMillis() - time));
}
Тест опять ни про что, т.к. файловая система одинаково тормозит в любом языке.
//ListTEst
Хотя тест и так показывает превосходство java:
Их вариант 0.110с
Мой вариант 0.070с
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
public static void main(String[] args) {
long time = System.currentTimeMillis();
for ( int i = 0 ; i < 1000 ; i++) {
ArrayList v = new ArrayList( 1010 );
v.add("a");
v.add("b");
v.add("c");
v.add("d");
v.add("e");
v.add("f");
v.add("g");
for ( int j = 0 ; j < 1000 ; j++) {
v.add(j);
v.get(j);
}
}
System.out.println("time: " + (System.currentTimeMillis() - time));
}
Дальше говорить бесполезно, и так всё очевидно.
Достаточно посмотреть на
Object Allocation 23.65 211.11 Java 8X Faster than Python
чтобы задаться вопросом:
А правда ли есть смельчаки пишущии в OOP стиле на Python'e, если самая распространённая операция с объектами это 8х-ый проигрыш java?
А как тогда обстоят дела с эффективностью полиморфных вызовов?
