Как тут уже сказали, проблема в том, что во многих примерах код явы просто скопировали на с++ и изменили, чтоб скомпилиось. Именно это не честно, потому что если бы человек изначально "думал" на си++, он бы реализовал решение по другому. Эту мысль высказал VOS, а я с ней согласился и добавил свою догадку об одной из причин обгона джавой сей в случае этих примеров.






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

Особенно использование сторонних менеджеров памяти  

Это достоверная инфа, правда игру Закон и порядок я к сожалению "не щупал". Но Chrome и Xtreme Rally сделаны одной фирмой на одном и том же движке. А Chrome выиграл даже конкурс от Sun Microsystems.

Это сообщение отредактировал(а) $tatic - 19.3.2007, 20:05

А особенно при использовании agile методологий,  где предпочтительнее прозрачный код чем мифическое ускорение на три наносекунды   

Если прийдешь к осознанию, что это нужно, то это дело пяти минут (если, конечно, не самому писать).


Прозрачность никуда не денется, если использовать язык естественным образом. 

Тут у нас религиозная война не начинается, случаем?   

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

Итак первоначальный тест:




Первый тест - 6781 мс
Второй         - 421 мс

Комп - P4  2,4 Ггц  512 МБ
На нем запущен CBuilder, NOD, MS SQL, Oracle, Firebird и т.д. (лень выгружать было)

Это сообщение отредактировал(а) batigoal - 20.3.2007, 11:41

Это сферический конь в вакуме. Смысл имеют только относительные результаты.

Что же касается кода, то второй пример ни разу не эквивалентен первому. Т.к. во втором случае мы не можем освобождать память по мере необходимости, и если из 10 000 000 объектов нам нужен будет только один, то мы будем держать всю память занятой.

P.S. Не верю я что на машине с 512 Мб памяти и такой толпой запущенных программ:

можно комфортно работать. Те же MS SQL и Oracle, памяти жрут немерянно.

Изволите за ЦСКА болеть?
Согласен конечно. Но относительные результаты думаю очевидны.



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


Это если их активно юзать. Если только хранимки править, то не особо напрягает. А вот когда еще среда разработки для Java запускается, вот тогда не сладко  Но на Java я пока только под мобилы пишу. Впечатления самые положительные. 

Вот шикарный тест из LZMA SDK и Java и C# и оптимизтрованный C++ и Delphi:

Исходники и бинарники (1.6 MB) Данные прогона на моих компах 

alexsolo, 

1. Откуда исходники и под какой лицензией они распространяются?
2. Кто писал код?

LSD, http://www.7-zip.org/sdk.html
Try for yourself 

Не вижу ничего удивительного что жава работает с обычными числами по скорости как С/С++.
По моему основные тормаза по сравнению с С/С++ жаве добавляет ядреное ООП. Всетки большинство реальных приложений на жаве работают заметно медленее их аналогов на С++ и едят больше памяти.

В продолжение спора о BEA JRockit. Я продолжаю утверждать, что эта JVM лучше подходит для production-mode J2EE - приложений, даже если они крутятся не на WebLogic`е.

Вот, буквально на днях они выпустили JRockit для Java SE 6.

В качестве примера я взял на своём рабочем компе (P4, 2.8 GHz, 1GB  RAM, WinXP sp2) и протестировал старт сервера JBoss 4.0.5 под последними 5-ми и 6-ми версиями на данный момент. Ничего не настраивал, просто скачал и развернул архив. Результаты такие:

JRockit 6:


JRockit 5


Sun JDK 5:


А Sun JDK 6 почему-то вообще с ошибкой свалилась:

Сейчас, разберусь с 6-й JDK - ещё напишу...

Как лицензируется JRockit?

Дома тоже эта ошибка наблюдалась. Переставил - вроде пошло. Но машина другая (P4 3GHz, 2Gb RAM), так что - всё по-новой:

Sun JDK 6: 

Sun JDK 5: 

BEA JRockit 6: 

BEA JRockit 5: 

Тоесть у пятёрочки JRockit при избытке памяти производительность даже возросла...



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

Я думаю, дело в том, что к JRockit идут дополнительные инструменты для диагностики memory leak`ов  и тюнинга - вот их использование уже вроде бы платно, хотя их тоже можно и скачивать и юзать - но уже в права на них я не вникал...