LINUX.ORG.RU

Java SE 6 Performance White Paper


0

0

Представлен сравнительный обзор показателей производительности и улучшений в масштабируемости Java стандартной версии 6 (Update 2) в сравнении с предыдущей версией платформы Java 5.0.

Java SE 6 включает несколько новых функций и усовершенствований для повышения производительности во многих частях платформы. Улучшения включают:

  • синхронизованные оптимизации выполнения, оптимизации производительности компилятора;
  • новый параллельный уплотняющий сборщик мусора (Parallel Compaction Collector);
  • более эргономичный параллельный низколатентный сборщик мусора (Concurrent Low Pause Collector);
  • ускорение запуска приложений.
Сравнение современной версии Java SE 6 Update 2 ведётся с предыдущей версией платформы -- Java SE 5 FCS.
Так, например, производительность операций ввода-вывода Java 6 в два раза выше, чем у Java 5.0; производительность корпоративных систем по тесту SPECjbb2005 Benchmark возросла на 70%; производительность Java в популярном тесте VolanoMark Benchmark выросла более чем на 40%; скорость запуска приложений увеличилась на 15-20%.

Также приводятся ссылки на материалы, посвящённые отдельным оптимизациям и тестам. В частности, интерес представляет отимизация сборки мусора и уменьшения потребления памяти в отдельной статье "Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning":
http://java.sun.com/javase/technologi...

Другие ссылки приведены по ходу обзора и в его конце.

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Ответ на: комментарий от alebu

> Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с 512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы даннных и апп сервер, то памяти таки докинул.

тормозит и на более хорошем железе. а Вы своё лечение самовняшением оставьте, это в недалёком будущем может привести к аутизму

gaa ★★
()
Ответ на: комментарий от dave

> Данные уникальны, а управляющий ими код - общий.

Кажется еще есть случай, когда данные - общие, но это уже один из вариантов деплоймента. И несколько экзотичный для обычных библиотек.

dave ★★★★★
()
Ответ на: комментарий от dave

> Официальная дока (MSDN) говорит

не читайте с утра советских газет

> поскольку JIT компилятор может динамически оптимизировать код, а статический компилятор - нет.

теоретически можно и конус на вершину поставить. где практическое применение этой теоретической возможности? даже знатные вруны из микрософт не говорят о том, что оно у них реализовано.

> К тому же, в единицу времени далеко не все части кода используются. Даже во время одного запуска. Это справедливо для больших приложений. Еще один плюс в пользу JIT.

какой плюс? перекомпилить при каждом запуске выйдет дороже однократного компилирования, пусть даже и не всё придётся каждый раз перекомпиливать

> JIT - очень эффективная технология.

...развода покупателей на бабки

gaa ★★
()
Ответ на: комментарий от gaa

> перекомпилить при каждом запуске выйдет дороже однократного компилирования, пусть даже и не всё придётся каждый раз перекомпиливать

По ссылке ходил? Там почти половина написаного относится к динамической оптимизации для JIT компилятора в случае multi-threading. Все-таки их писанина выглядит как-то авторитетнее твоей :)

dave ★★★★★
()
Ответ на: комментарий от dave

>> перекомпилить при каждом запуске выйдет дороже однократного компилирования, пусть даже и не всё придётся каждый раз перекомпиливать

> По ссылке ходил?

какой ссылке? я отвечал на вопрос, более общий чем тема новости.

> Там почти половина написаного относится к динамической оптимизации для JIT компилятора в случае multi-threading.

ненужных потерь в скорости запуска это не отменяет. про кеширование в обсуждении уже говорили, да вот что-то оно пока что от родителями жавы не реализовано

gaa ★★
()

кстати, это хороший маркетинговый ход: написать тормозное говнецо, а потом радовать тем, как его ускорили :)

gaa ★★
()
Ответ на: комментарий от Bohtvaroh

> Кроме eclipse что-нибудь сравнивал? Я бы попробовал сравнить скорость запуска, к примеру, jboss, когда тот будет оффициально поддерживать 6-ку.

У JBOSS на 6-ке проблем не замечено.

Aceler ★★★★★
()
Ответ на: комментарий от anonymous

>...А в кэше скомпилированный код, лежащий на диске, может быть изменен вредоносной программой, следовательно, надо вводить механизм контроля за сохранностью кэша...

Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

xTERM ★★
()
Ответ на: комментарий от xTERM

Да и вообще, не в кеше дело. Ладно с ним. Главное, чтобы classpath от sun поставлялся прекомпилиный. Он лежит не в кеше, а там, где Ява. А байткода там дохера, и его компиляция сильно все затормаживает.

xTERM ★★
()
Ответ на: комментарий от gaa

> тормозит и на более хорошем железе.

А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

По сравнению с нативным кодом на C - конечно.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

>> тормозит и на более хорошем железе.

> А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

тормозит - это объективный критерий. если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

"среагировала" в случае гуёвой программы - поменяла изображение на экране. причём полностью, а не забелила окошко и медленно его перерисовывает.

следовательно, эклипс _тормозит_ на хорошем железе.

> По сравнению с нативным кодом на C - конечно.

не все явисты это понимают. а если понимают, то начинают прикрываться защищённостью, потом лёгкостью разработки, а потом или пропадают или переходят на оскорбления.

gaa ★★
()
Ответ на: комментарий от xTERM

>> ...А в кэше скомпилированный код, лежащий на диске, может быть изменен вредоносной программой, следовательно, надо вводить механизм контроля за сохранностью кэша...

> Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

1. У Микрософта, реализовавшего обсуждаемую структуру в .NET, логическое развитие идеи защиты файлов операционной системой привело к появлению Висты. В глобальном кэше сборок во всех версиях винды, где есть дотнет, работает упомянутый мною механизм доверия, который приводит к быстродействию, сопоставимому с явой.

2. Помимо сохранности кода, при кэшировании скомпилированных классов придется включать еще некоторый механизм контроля версий классов (например, при входе на два разных сайта мы загрузили две разные версии сласса с одним и тем же именем...), что приводит к необходимости заводить систему типа COM, от которой убегает даже Микрософт. Именно это, насколько я понимаю, и сделано в Excelsior JET, и потому этот пакет такой дорогой.

anonymous
()
Ответ на: комментарий от gaa

> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

Если программа не умеет работать с обменом видеостраниц, то тормозит ее разработчик. (С) корпорация Майкрософт.

anonymous
()
Ответ на: комментарий от anonymous

>>> ...А в кэше скомпилированный код, лежащий на диске, может быть изменен вредоносной программой, следовательно, надо вводить механизм контроля за сохранностью кэша...

>> Если вражеская программа так просто может подменять файлы, какие хочет, то почему она не может подменить сразу сам jre? За сохранностью файлов должна отвечать операционная система, а подобные комменты - любимая гипнотическая фраза M$ по-поводу безопасности, для впихивания своего говна в горло всякого быдла.

> 2. Помимо сохранности кода, при кэшировании скомпилированных классов придется включать еще некоторый механизм контроля версий классов (например, при входе на два разных сайта мы загрузили две разные версии сласса с одним и тем же именем...),

советую посмотреть, как реализуется кеширование веб-страниц(например, глянуть кеш Вашего браузера) и понять, что версионирование в таком случае не нужно

> что приводит к необходимости заводить систему типа COM, от которой убегает даже Микрософт. Именно это, насколько я понимаю, и сделано в Excelsior JET, и потому этот пакет такой дорогой.

ком тут не нужен. потому что не нужно версионирование.

gaa ★★
()
Ответ на: комментарий от Aceler

>А вы поставьте вопрос по-другому - тормозит _по сравнению с чем_?

>По сравнению с нативным кодом на C - конечно.

Только с ним и имеет смысл сравнивать.

tailgunner ★★★★★
()
Ответ на: комментарий от gaa

> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

Только вот программа может рисовать Hello World, а может заниматься парсингом туевой хучи файлов. И все равно вам для оценки тормозопригодности придется сравнивать с аналогами :). Да, я знаю, что emacs распарсит исходники JBOSS быстрее.

> не все явисты это понимают. а если понимают, то начинают прикрываться защищённостью, потом лёгкостью разработки

Это не защита и не прикрытие. Просто надо понимать, чем платишь и за что. Eclipse, приведенный для примера, дает разработчикам RCP - переносимую платформу, что не дает C, по крайней мере, так легко.

Aceler ★★★★★
()
Ответ на: комментарий от tailgunner

> Только с ним и имеет смысл сравнивать.

По производительности? А по переносимости будем сравнивать с bash, а по объектной модели будем сравнивать с python? А давайте наоборот - производительность сравним с python, объектную модель - с bash, а перносимость - с С?

Aceler ★★★★★
()
Ответ на: комментарий от anonymous

> Помимо сохранности кода, при кэшировании скомпилированных классов придется включать еще некоторый механизм контроля версий классов (например, при входе на два разных сайта мы загрузили две разные версии сласса с одним и тем же именем...), что приводит к необходимости заводить систему типа COM

Ты, похоже, вообще ничего о COM не знаешь. А в описанной ситуации достаточно точного хеширования.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

>> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

> Если программа не умеет работать с обменом видеостраниц, то тормозит ее разработчик. (С) корпорация Майкрософт.

если гуёвая программа тормозит(в описанном мной смысле)[это понятие можно обобщить для любой интерактивной программы], то одного из разработчиков программы надо уволить. но мне, как конечному пользователю нет разницы, кого: разработчика программы, графического тулкита, языка программирования или компилятора/интерпретатора. я вижу, что программа тормозит и точка.

gaa ★★
()
Ответ на: комментарий от Aceler

>> Только с ним и имеет смысл сравнивать.

>По производительности?

Да. именно по ней. Кукарекали про нативный код? Пусть отвечают за свои слова.

> А по переносимости будем сравнивать с bash, а по объектной модели будем сравнивать с python?

К чему ты это?

tailgunner ★★★★★
()
Ответ на: комментарий от Aceler

>> если программа не среагировала на нажатие кнопки за 1/25 секунды, то она тормозит.

> Только вот программа может рисовать Hello World, а может заниматься парсингом туевой хучи файлов.

для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

gaa ★★
()
Ответ на: комментарий от gaa

> ненужных потерь в скорости запуска это не отменяет. про кеширование в обсуждении уже говорили, да вот что-то оно пока что от родителями жавы не реализовано

В качестве исключения (вроде бы на форуме мы еще не сталкивались..).

По ссылке описаны некоторые методы-трюки, которые позволяют в некоторых случаях выполнять синхронные секции без фактической блокировки, либо уменьшают количество таких блокировок. Как известно, блокировки очень сильно тормозят много-поточные приложения, но во многих случаях они просто необходимы.

Теперь вот какая штука. Возможно, эта информация уже устарела, но в свое время Swing (Java GUI API) был написан так, что в качестве коллекций использовался повсеместно класс Vector, чьи методы по ошибке первых проектировщиков были сделаны синхронными (это признал потом сам Гослинг).

Так вот, если JIT умеет правильно определять места, где блокировкой можно пренебречь (а Swing-код по-определению однопочный, хотя и базируется на много-поточном AWT), то это может значительно ускорить выполнение... Вот такие пироги.

Что касается быстроты откомпилированного кода на C. Он будет быстрее в случае каких-нибудь линейных вычислений. Но в случае много-поточного кода и обработки данных со сложной иерархией связка JIT + GC может оказаться быстрее. Но это уже не уровень HelloWorld приложений, а значительно выше... Если бы так было все просто...

Да, кстати, системная библиотек отчасти закеширована в java 6 update 2.

dave ★★★★★
()
Ответ на: комментарий от tailgunner

> Да. именно по ней. Кукарекали про нативный код? Пусть отвечают за свои слова.

А, в данном случае! В данном случае да.

> К чему ты это?

Уже ни к чему.

Aceler ★★★★★
()
Ответ на: комментарий от gaa

> напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

Интерактивные программы _вообще_ в java не тормозят. Тормозит конкретно Eclipse. Почему там не показывают червяка и тем более не пускают отдельный процесс (в java это делается тремя байтами) - вопрос не ко мне.

Aceler ★★★★★
()
Ответ на: комментарий от dave

>> ненужных потерь в скорости запуска это не отменяет. про кеширование в обсуждении уже говорили, да вот что-то оно пока что от родителями жавы не реализовано

> По ссылке описаны некоторые методы-трюки, которые позволяют в некоторых случаях выполнять синхронные секции без фактической блокировки, либо уменьшают количество таких блокировок. Как известно, блокировки очень сильно тормозят много-поточные приложения, но во многих случаях они просто необходимы.

я с этим не спорю. но я говорил не про это.

я говорил про то, что от излишней jit-компиляции при первой загрузке участка кода можно избавиться. хотя бы кешем.

> Что касается быстроты откомпилированного кода на C. Он будет быстрее в случае каких-нибудь линейных вычислений. Но в случае много-поточного кода и обработки данных со сложной иерархией связка JIT + GC может оказаться быстрее. Но это уже не уровень HelloWorld приложений, а значительно выше... Если бы так было все просто...

опять "может". в той программе, которая запускается сегодня, теоретически возможные оптимизации роли не играют.

> Да, кстати, системная библиотек отчасти закеширована в java 6 update 2.

вот это хорошо.

gaa ★★
()
Ответ на: комментарий от Aceler

> Тормозит конкретно Eclipse.

B NetBeans тоже, по крайней мере с Си++ плагином :)

tailgunner ★★★★★
()
Ответ на: комментарий от Aceler

>> напоминаю, что определение понятия _тормозит_ я дал для _интерактивных_ программ.

> Интерактивные программы _вообще_ в java не тормозят. Тормозит конкретно Eclipse.

netbeans тоже подтормаживает. других жава-приложений сходу вспомнить не могу

> Почему там не показывают червяка и тем более не пускают отдельный процесс (в java это делается тремя байтами) - вопрос не ко мне.

там пускают червяка... но даже на операции банальной прокрутки большого файла в редакторе появляются тормоза. так что не только в эклипсе дело.

gaa ★★
()
Ответ на: комментарий от gaa

> советую посмотреть, как реализуется кеширование веб-страниц(например, глянуть кеш Вашего браузера) и понять, что версионирование в таком случае не нужно

Да, если страница изменена, то она подкачивается с сервера. Соответственно, если (контрольная сумма? версия?) класса изменилась, то класс перекомпилируется. Трудности начинаются, когда поставщики классов с одинаковыми именами -- разные, и номер версии не помогает. Такой ситуации в обозревателе не бывает (для избежания есть специальный механизм в обозревателе, называемый сеансом). Теоретически может не помочь даже контрольная сумма (хотя это уже патология), хотя Сан подумал и о том случае, и о другом.

> ком тут не нужен. потому что не нужно версионирование.

См. выше. Отсутствие версионирования ухудшает итоговое быстродействие. Вопрос в том, приемлемым образом или нет. Микрософт проделал опыт с Вистой, разрешив частичное кэширование. Получилось не очень приемлемо.

anonymous
()
Ответ на: комментарий от Aceler

>Тормозит конкретно Eclipse

Согласен. Только Eclipse со своей SWT, написаной поверх нативных гуевых библиотек тормозит. Остальные же животные (NetBeans например) - ПОЛЗАЮТ!

xTERM ★★
()
Ответ на: комментарий от dave

>Так вот, если JIT умеет правильно определять места, где блокировкой можно пренебречь (а Swing-код по-определению однопочный, хотя и базируется на много-поточном AWT), то это может значительно ускорить выполнение... Вот такие пироги.

Да, да, на Swing это заметно ;) Он прямо летает благодаря этим пирогам.

xTERM ★★
()
Ответ на: комментарий от gaa

> я говорил про то, что от излишней jit-компиляции при первой загрузке участка кода можно избавиться. хотя бы кешем.

Это имеет смысл в случае системных библиотек, а они закешированы (java 6).

Потом нужно понимать, что сам парсинг байт-кода - это мизерная часть обработки. Сложность JIT - в исполнении.

> в той программе, которая запускается сегодня, теоретически возможные оптимизации роли не играют.

Каждый судит со своей колокольни. У меня есть опыт программирования на многих языках, включая так нравившийся мне в школьные годы ассемблер PDP11 (для БК и ДВК). Были проекты, где компилированный C/C++ код был одним из лучших решений. Но мой последний проект такой, где Java или .NET решение по многим параметрам превосходит возможное C/C++/Delphi/Ada решение. В том числе с точки зрения производительности и скорости исполнения, не говоря, уже о времени разработки. Многое зависит от задачи.

Здесь я обычно люблю на ссылаться на отечественную среду моделирования AnyLogic, написанную на Java. По-моему хороший пример того, что было бы очень трудно создать на C...

dave ★★★★★
()
Ответ на: комментарий от Aceler

>> netbeans тоже подтормаживает. других жава-приложений сходу вспомнить не могу

> http://www.pulpgames.net/scared/

Быстродействие на уровне машинного кода на P166MMX без ускорения трехмерной графики (ИЛИ БЫСТРЕЕ -- но вот насколько???) -- на Core 2 Duo 7200.

Примеры нехарактерные. Или компьютер слишком мощный...

Сам работаю с нетбинзами на P4-2530 с гигабайтом памяти. Быстродействие вполне нормальное (у эклипса гораздо хуже, у интеллиджея несколько лучше).

anonymous
()
Ответ на: комментарий от anonymous

> Отсутствие версионирования ухудшает итоговое быстродействие.

непонятно, откуда взято подобное утверждение

gaa ★★
()
Ответ на: комментарий от gaa

alebu (18.11.2007 17:49:48)> Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с 512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы даннных и апп сервер, то памяти таки докинул.

В 1998 году я запускал Borland JBuilder 1.0 и 2.0 Enterprise Edition на Pentium 133МГц и 32Мб RAM (потом добавил до 64Мб) с операционной системой WindowsNT 4.0 Workstation. И чё-то всё-таки делал в редакторе кода, писал что-то для работы с GUI и 2D-графикой. Какое-то время изучал возможности Symantec Visual Cafe -- очень прожорливая штука, потому не решился на неё перейти с JBuilder'а.

Конечно, тормоза были во всём, так как оперативной памяти было явно недостаточно, свопило всё что можно при переключении из редактора кода в визуальный дизайнер форм и обратно. Хотя WinAmp в это время проигрывал MP3 без запинок. Обе среды были написаны на C++, а Java 1.1 выступала, видимо, как движок нативных компонентов -- очень странная архитектура, созданная в расчёте на скорость, но не выдерживающая никакой критики по быстродействию. В те времена AWT было ещё не оптимизировано, так что среды на AWT были гораздо тормознее полунативных. Отдельная баблиотека Swing была ещё экспериментальной, так что мечтать о быстрой графике и GUI на Java было рано.

На соседних машинках с такой же аппаратной конфигурацией люди работали в Delphi 2.0 более-менее комфортно. Можно было гонять по 10 мегабитной сети огромные по тем временам наборы данных. Да и Java-приложения при работе с удалёнными СУБД на SQL не отличались по скорости, но вот GUI сильно тормозил, и поэтому дельфины, привыкшие к моментальной реакции интерфейса на действия офисного пользователя, воротили нос от этого "кошмара".

У меня всегда было предчувствие (не смутил даже первый запуск JBuilder'а 1.0 на Pentium 133/16Мб) что Java всё-таки будет мэйнстримом и со временем станет лучше Delphi. А те, кто занимался разработкой в Delphi, к стыду своему перестанут считать Java тормозной игрушкой. Так и вышло.

С открытием Eclipse и ускорением разработки NetBeans в 2001-2002 годах всё менялось буквально на глазах. Нативные среды разработки не обзаводились никакими преимуществами даже в плане быстрого рефакторинга, а тем временем Java увеличила производительность чуть ли не в разы с каждой новой версией java 1.2 -> 1.3 -> 1.4 ->... Теперь же Eclipse, IDEA и NetBeans фактически являются мэйнстримом средств разработки, а фавориты Delphi и VS -- вчерашний день.

Железо тоже увеличивало производительность линейно. Обычные компы уже в 2005 году стали иметь процессор с частотой от 2ГГц с внешней быстрой шиной от 1ГГц и память от 1Гб и выше. Таким образом, увеличение производительности железа и алгоритмическая оптимизация обеспечили почти квадратичное повышение производительности платформы Java, и она всё больше переставала быть "тормозной игрушкой" в руках жабофилов.

В том же году (2005г.) продолжался "Мобильный бум" и распространение J2ME-игр, но скорее всего две параллельные вселенные J2SE и J2ME никак не связаны между собой. Хотя скорость разработки игр напрямую зависела от производительности настольной версии Java и компилятора javac, а также от скорости работы эмулятора.

"Новые" интерпретирующие технологии на основе XML, SOAP и впоследствии AJAX не уничтожили Java, а придали ей большую живучесть и приспособляемость, несмотря на старания Microsoft вкупе с .Net.



gaa (18.11.2007 20:52:03)>тормозит и на более хорошем железе. а Вы своё лечение самовняшением оставьте, это в недалёком будущем может привести к аутизму

Значит я болен с 1998 года (когда у меня тогда даже компьютера своего не было). И ещё несколько миллионов разработчиков на Java заразились этой болезнью и неизлечимо больны... Прям какая-то эпидемия ходит по планете с 1995 года. ;)

iZEN ★★★★★
() автор топика
Ответ на: комментарий от dave

>> я говорил про то, что от излишней jit-компиляции при первой загрузке участка кода можно избавиться. хотя бы кешем.

>Это имеет смысл в случае системных библиотек, а они закешированы (java 6). Потом нужно понимать, что сам парсинг байт-кода - это мизерная часть обработки. Сложность JIT - в исполнении.

ещё раз повторю: "дорогой" форк - это инвариант любого не-нативного языка. не важно, что потом будет тормозить или не тормозить исполнение, форк от этого не подешевет.

>> в той программе, которая запускается сегодня, теоретически возможные оптимизации роли не играют.

> Каждый судит со своей колокольни. У меня есть опыт программирования на многих языках, включая так нравившийся мне в школьные годы ассемблер PDP11 (для БК и ДВК). Были проекты, где компилированный C/C++ код был одним из лучших решений. Но мой последний проект такой, где Java или .NET решение по многим параметрам превосходит возможное C/C++/Delphi/Ada решение. В том числе с точки зрения производительности и скорости исполнения, не говоря, уже о времени разработки.

давайте сразу достанем линейки :)

> Многое зависит от задачи.

да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

gaa ★★
()
Ответ на: комментарий от iZEN

>alebu (18.11.2007 17:49:48)> Кстати, Athlon 2000+ 1GB RAM. 3 года - тормозов нет. Раньше сидел с 512 МБ , но когда начал в довеску запускать Кота Тома, всякие базы даннных и апп сервер, то памяти таки докинул.

>В 1998 году я запускал Borland JBuilder 1.0 и 2.0 Enterprise Edition на Pentium 133МГц и 32Мб RAM (потом добавил до 64Мб) с операционной >системой WindowsNT 4.0 Workstation. И чё-то всё-таки делал в редакторе кода, писал что-то для работы с GUI и 2D-графикой. Какое-то время изучал возможности Symantec Visual Cafe -- очень прожорливая штука, потому не решился на неё перейти с JBuilder'а.

>Конечно, тормоза были во всём, так как оперативной памяти было явно недостаточно, свопило всё что можно при переключении из редактора кода в визуальный дизайнер форм и обратно. Хотя WinAmp в это время проигрывал MP3 без запинок. Обе среды были написаны на C++, а Java 1.1 выступала, видимо, как движок нативных компонентов -- очень странная архитектура, созданная в расчёте на скорость, но не выдерживающая никакой критики по быстродействию. В те времена AWT было ещё не оптимизировано, так что среды на AWT были гораздо тормознее полунативных. Отдельная баблиотека Swing была ещё экспериментальной, так что мечтать о быстрой графике и GUI на Java было рано.

>На соседних машинках с такой же аппаратной конфигурацией люди работали в Delphi 2.0 более-менее комфортно. Можно было гонять по 10 мегабитной сети огромные по тем временам наборы данных. Да и Java-приложения при работе с удалёнными СУБД на SQL не отличались по скорости, но вот GUI сильно тормозил, и поэтому дельфины, привыкшие к моментальной реакции интерфейса на действия офисного пользователя, воротили нос от этого "кошмара".

>У меня всегда было предчувствие (не смутил даже первый запуск JBuilder'а 1.0 на Pentium 133/16Мб) что Java всё-таки будет мэйнстримом и со временем станет лучше Delphi. А те, кто занимался разработкой в Delphi, к стыду своему перестанут считать Java тормозной игрушкой. Так и вышло.

>С открытием Eclipse и ускорением разработки NetBeans в 2001-2002 годах всё менялось буквально на глазах. Нативные среды разработки не обзаводились никакими преимуществами даже в плане быстрого рефакторинга, а тем временем Java увеличила производительность чуть ли не в разы с каждой новой версией java 1.2 -> 1.3 -> 1.4 ->... Теперь же Eclipse, IDEA и NetBeans фактически являются мэйнстримом средств разработки, а фавориты Delphi и VS -- вчерашний день.

>Железо тоже увеличивало производительность линейно. Обычные компы уже в 2005 году стали иметь процессор с частотой от 2ГГц с внешней быстрой шиной от 1ГГц и память от 1Гб и выше. Таким образом, увеличение производительности железа и алгоритмическая оптимизация обеспечили почти квадратичное повышение производительности платформы Java, и она всё больше переставала быть "тормозной игрушкой" в руках жабофилов.

>В том же году (2005г.) продолжался "Мобильный бум" и распространение J2ME-игр, но скорее всего две параллельные вселенные J2SE и J2ME никак не связаны между собой. Хотя скорость разработки игр напрямую зависела от производительности настольной версии Java и компилятора javac, а также от скорости работы эмулятора.

>"Новые" интерпретирующие технологии на основе XML, SOAP и впоследствии AJAX не уничтожили Java, а придали ей большую живучесть и приспособляемость, несмотря на старания Microsoft вкупе с .Net.

>gaa (18.11.2007 20:52:03)>тормозит и на более хорошем железе. а Вы своё лечение самовняшением оставьте, это в недалёком будущем может привести к аутизму

>Значит я болен с 1998 года (когда у меня тогда даже компьютера своего не было). И ещё несколько миллионов разработчиков на Java заразились этой болезнью и неизлечимо больны... Прям какая-то эпидемия ходит по планете с 1995 года. ;)

неплохо сказано ;)

xTERM ★★
()
Ответ на: комментарий от gaa

>для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(1/25 секунды), то программа тормозит.

То есть когда ты в Vim|Emacs|VisualStudio нажимаешь "Run", у тебя среда компилирует проект и запускает его менее чем за 1/25секунды? Круто. Ничего что у меня в Eclipse я жду немножко дольше? А, кстати, когда ты нажимаешь "Поместить" на странице http://www.linux.org.ru/view-message.jsp?msgid=2278155 понимаешь ли ты, что тормозит не сама Java, которая обрабатывает твое нажатие, а твое сообщение еще успевает поместиться в базу и уже потом Java отдает тебе страницу с твоим ответом?

Кстати, когда maxcom поставит на LOR Java 6.0 update 3? Хотелось бы посмотреть, как форум залетает

anonymous
()
Ответ на: комментарий от xTERM

> Да, да, на Swing это заметно ;) Он прямо летает благодаря этим пирогам.

Юмор оценил :)

А теперь серьезно. Те же операции с графикой отнимают куда больше времени, чем соблюдение синхронности Vector. И правильное использование ClipRectangle занимает куда более важное место.

dave ★★★★★
()
Ответ на: комментарий от gaa

> ещё раз повторю: "дорогой" форк - это инвариант любого не-нативного языка. не важно, что потом будет тормозить или не тормозить исполнение, форк от этого не подешевет.

Не совсем понял смысл написанного. Тут все так относительно... Уже не всегда разберешь, где натив, а где виртуалка.

> да. но не всякий язык(в отличие от жавы) тянут во _все_ типы задач.

Но у меня нет такого ощущения, по крайней мере, ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

dave ★★★★★
()
Ответ на: комментарий от anonymous

> Кстати, когда maxcom поставит на LOR Java 6.0 update 3? Хотелось бы посмотреть, как форум залетает

А с чего ему быстрее летать? Документ по ссылке старый. У меня java и та новее: build 1.6.0_02-b06.

dave ★★★★★
()
Ответ на: комментарий от dave

>ядро Solaris никто еще не вздумал переписать на Java. Или, может быть, я что-то пропустил? :)

Пропустили. Уже пробегала новость про внутриядерную JVM и драйвер на Java в Solaris. :)

iZEN ★★★★★
() автор топика
Ответ на: комментарий от dave

>У меня java и та новее: build 1.6.0_02-b06.

А у меня всё равно длиннее:
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)

:))

iZEN ★★★★★
() автор топика
Ответ на: комментарий от dave

>А теперь серьезно. Те же операции с графикой отнимают куда больше времени, чем соблюдение синхронности Vector. И правильное использование ClipRectangle занимает куда более важное место.

Опереции с графикой начали оптимизировать с Java2 1.4. Тогда уже было задействовано аппаратное ускорение 2D (например, Swing для отрисовки своих контролов в Windows уже тогда работал через DirectDraw).
Класс Vector переписали с использованием нового каркаса Java Collections Framework тоже в той же версии, если мне не изменяет память.
Потом начали проводить разные оптимизации в JVM.

iZEN ★★★★★
() автор топика

/me только что закончил установку и конфигурацию Jboss Portal на Celeron 400 и 128 метров ОЗУ. Java 1.6 без апдейта. Если с апдейтом будет лучше - поставлю апдейт.

Кричащие Java - тормоз идут покупать мне новый процессор.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

>только что закончил установку и конфигурацию Jboss Portal на Celeron 400 и 128 метров ОЗУ.

а) кто такой /me?

б) опиши ощущения. Это должно быть что-то незабываемое, ведь JBoss Portal требует 512Мб памяти

anonymous
()
Ответ на: комментарий от Aceler

> установку и конфигурацию Jboss Portal на Celeron 400 и 128 метров ОЗУ
ну как запустишь под ним чет более менее реальное, отпостишься.

ilnurathome
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.