Java SE 6 Performance White Paper

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К чему ты это?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уже ни к чему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 года. ;)

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

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

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

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

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

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

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

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

>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 года. ;)

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

>для длительный операций принято делать отдельный поток и показывать в гуйке синего червяка. если это не сделано _мгновенно_(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? Хотелось бы посмотреть, как форум залетает

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

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

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

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

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

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

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

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

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

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

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

>У меня 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)

:))

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

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

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

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

кстати никто не юзал жабаос
http://java.sun.com/developer/products/JavaOS/download.html
она вроде как unix-like должна бы была быть
Как ощущения?

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

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

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

Что за рехня? Как ее запускать-то?

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

> Что за рехня? Как ее запускать-то?
Да это я ссылкой загнался на ее sdk дал
http://java.sun.com/developer/products/JavaOS/
http://www.javapos.com