.NET vs. Java

Мега статья. И о чём она говорит? А о том, что не стоит пользоваться сериализацией если она вас не устравивает по скорости. А автор просто монстр: .NET vs Java. Забыл только указать, что только на примере какой-то не понятоной сериализации (где сорцы?). И машина просто супер серверная: Pentium II 366, 256 RAM. Цирк на дроте а не статья.

так так ... по моему пора мочить козлов за такие загалоФФки ...

Сравнение для идиотов. Сколько можно такую пургу постить? Ни тестов объективный, ни версий актуальных, ни выводов. Нахрена эту новость было подтверждать?

"Вторая причина: каким бы мощным ни был диалект SQL, реализованная на нем логика все равно будет работать в десятки, а то и в сотни раз медленнее, чем логика, реализованная на Java, C++ или C#."

Это сравнение не для нас, простых смертных, а для журналистов, парящих над серверами, и видящих все с высоты своего полета... Хай летят себе далеко-далеко...

Lame. Что за бред?! Какого эту х%рню постят?

> Первый и основной недостаток заключается в том, что необходим

программист, который знаком с тем или иным диалектом SQL, для того

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

С каких пор необходимость в программисте это недостаток да еще и основной.

> Кроме всего прочего, SQL-скрипты достаточно сложны для понимания -

даже если вы их сами написали всего пару дней назад.

Как можно писать и не понимать?

Вывод:

Кароче бред какой то.

... и был ночно дозор, чтобы следить за чилами тьмы, и был дневной дозор, чтобы контролировать силы света и было равновесие... (с) какая-то дурацкая комедия

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

>Как можно писать и не понимать?

Хи хи хи, знаете, есть такие, "квадратные", экрана на два, на три? Без стаканА хрен разберёшь.

В общем-то позоров 4 у Лукьяненки: вечерний, дневной, сумеречный и ночной. :-)))

а интерпритаторы какие? или нашли ещё один повод поругать мелких?

Два-три еще нечего, Мне тут с месяц назад пришлось править отчетик на 15 экранов - вот это была сила :)

ARia

Вообще-то, "дозоров" три, а не четыре. "Вечерний" и "Сумеречный" - это одно и то же, просто первое названи "черновое" :-)

А-а-а... Ну ОК. От одного позора ты Сережку отмазал. :-)

Да чуствуется автор вообще безбашенный. Достаточно почитать ещё одну его статью http://www.citforum.ru/programming/digest/lang_test/ Все остальные реализации теста на других языках программирования являются абсолютно идентичными. Платформа - Linux RedHat 9 (celeron 1700) под VmWare. Язык - Perl. * логика: 6 секунд; * логика + конкатенация строки: интерпретатор не справился с выполнением теста. Тест выполнялся более десяти минут. Мне надоело ждать, и я прекратил его выполнение.

Платформа - Linux RedHat 9 (Сeleron 1700) под VmWare. Язык - PHP4.2.2

* логика: 15 секунд; * логика + конкатенация строки: тест не выполнен с ошибкой интерпретатора - "превышено время ожидания 30 секунд - выполнение прервано".

Придурок в квадрате. Настраивать время выполнения скрипта надо. Более того не очень понятно почему в его тестах так всё долго работало.

Да это клиника!

> То есть, говоря проще, приложение, построенное по современной архитектуре, должно использовать базу данных в режиме ANSI SELECT/UPDATE ...

> каким бы мощным ни был диалект SQL, реализованная на нем логика все равно будет работать в десятки, а то и в сотни раз медленнее, чем логика, реализованная на Java, C++ или C#.

Хотелось бы посмотреть, как автор этого опуса реализует например аналитические ф-ции на Java/C#, да еще чтобы они были "в десятки, а то и в сотни раз" эффективнее встроенных.

.NET vs. Java: победил PERL!

Вообще мне ещё не понятно, что сложные хранимые процедуры являются минусом, из-за которых приходится отказываться. Интересно автор знает как пишутся биллинговые системы для операторов сотовой связи? Там как раз БД на кластере с просто тучей разных хранимых процедур и никто пока ни от чего не отказался.

>Вообще-то, "дозоров" три, а не четыре. "Вечерний" и "Сумеречный" - >это одно и то же, просто первое названи "черновое" :-)

Вообще-то есть еще нелукьянинские "Дозоры", и мне лично они нравятся куда больше.

где таких придурков выращивают?

>Более того не очень понятно почему в его тестах так всё долго работало.

А че непонятного-то ? Конкатенация строки - по жизни тормозная операция: http://www.rsdn.ru/Forum/Message.aspx?mid=715215&only=1 -- Bozo

>Вообще-то есть еще нелукьянинские "Дозоры", Они вообще вроде как васильевские+лукьяниновские (именно в таком порядке).

>и мне лично они нравятся куда больше. Сразу видно - не "укоренной питерец" ;)))) Те обычно за "черную пальмиру" на Васильева кидаются ;))

Теперь я могу сказать - БЫЛО УЖЕ....

Притом в форуме, а не в новостях. Просто это неподобство теперь переместилось еще и на цитфорум.

Ньюсмейкеры подкачивают.

Статья некорректная по факту и смыслу. 1. Нет примера кода, без этого нельзя доверять данным тестов 2. Результаты могут (и будут) зависеть от железа, причём в тест не включены проверки на многопроцессорном сервере. 3. Почему Rotor и версия 1.0. Уже давно существует .NET Framework v1.1 в котором внутренние механизмы сериализации менялись и скорость повышалась 4. В качестве сравнения автор, на мой взгляд, целенаправленно выбрал область в которой Javs может превосходить C#, а то есть сериализация объектов. Но! Для больших приложений сериализация может просто вообще не использоваться, не говоря уже о том что .NET обладает множеством возможностей которых у Java нет или только только появились в JDK 1.4 5. Если статья использовалась в качестве наезна на MS, то это не та тема в которой можно развернуть удачную критику. У MS есть много других более слабых областей: безопасность, стоимость разработки и поддержки, закрытость кода и т.п.

Одним словом - неудачная статья

да ладно чего вы :-)

уже все давно знают, что тесты - дело вкуса и желания.

Надо бы эту "новость" удалить нах с главной страниццы.

Придется начать флейм на национальные темы...

А что делать?

> Придется начать флейм на национальные темы...

Спорим, национальность моих соседей лучше, чем твоя?

>Конечно, сегодня различные диалекты SQL, реализованные на серверах баз данных, позволяют делать с данными все или почти все. Практически это достаточно мощные процедурные языки, построенные на основе ANSI SQL92.

!? Если речь о PL\SQL ,то причем здесь ANSI 92? Если речь о диалекте SQL от Оракла, то какая нафиг процедурность? В равной степени все это относится и к Transact SQL, ну и к SQL-ю от MS.

>Еще одна причина: слабая переносимость нестандартного SQL-кода. Написанием бизнес-логики на северной стороне вы фактически отрезаете себе путь к использованию других баз данных или делаете его очень дорогостоящим.

Hint:MS linked server ,Oracle database link.

>Конечно, сегодня различные диалекты SQL, реализованные на серверах баз данных, позволяют делать с данными все или почти все. Практически это достаточно мощные процедурные языки, построенные на основе ANSI SQL92.

Та автор просто гуру. Он использовал DB с пеленок ещё, а сколько программ на различных языках он написал... Значит, он на SQL умеет ещё и вирусы писать, если SQL - это процедурные язык...

Ссылка на мощную статью! Бэйсик рульный язык! Я написал, что непонятно почему так медленно работало на интерпретируемых языках, не видно никакого кода. Да статья автору явно не удалась

своей национальности стесняешься настолько что за соседей прячессси?

Заголовок явно с претензией!

Хотелось бы посмотреть на исходники программмы, как во всех пноральных тестах. И прогнать тесты с серверной и клиентской VM - как известно скорость их работы весьма отличается. И почему именно JDK 1.3, а не что-нибудь посвежее?

ТщательнЕе надо, товарищи, тщательнЕе!

сперва хотелось бы посмотреть на автора

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

> Интересно автор знает как пишутся биллинговые системы для операторов сотовой связи? Там как раз БД на кластере с просто тучей разных хранимых процедур и никто пока ни от чего не отказался.

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

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

> Еще одна причина: слабая переносимость нестандартного SQL-кода. Написанием бизнес-логики на северной стороне вы фактически отрезаете себе путь к использованию других баз данных или делаете его очень дорогостоящим.

Скажите, а для чего вообще нужна эта переносимость SQL-кода? Для чего нужна проекту возможность работать с разными СУБД?

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

Если вы будете писать на SQL "переносимо", то вы автоматически закладываетесь на наихудшую из имеющихся реализаций БД. Нафига это надо?

На эту тему почитайте "Database Abstraction Layers Must Die!" http://jeremy.zawodny.com/blog/archives/002194.html

>на SQL умеет ещё и вирусы писать, если SQL - это процедурные язык...

не предерайтесь к словам. Понятно же, что автор имел в виду именно процедурные расширения SQL типа PL/SQL. То что у него бардак в мозгах не снимает проблемму совместимости различных процедурных расширений, да и расширений самого SQL, которые есть практически у всех производителей БД. В результате получаем нехилый гиморой при миграции с одной БД на другую. Хотя конечно эта тема несколько другого разговора чем .NET vs Java.

Ну наверное стоит спросить у поисковика или поговорить с кем-нибудь кто занимался написанием такой системы с большим числом клиентов. Себя не могу посоветовать, так как никаких хранимых процедур не использовал (mysql 3 версии у меня стоял), да и клиентов там несколько тысяч.

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

Вообще, конечно, если много вычислений (именно математических), то такой код лучше выносить в нативную программу/либу. А если же много операций с данными в самой БД, то тут хранимая процедура будет быстрее.

Выход - поставить Oracle 9 или 10G и для пакетов поставить опцию компиляции в нативный код. Тогда Оракл транслирует свой PL/SQL в С и компиляет полученные сорцы указанным админом компилятором. Получает на выходе DLL или SO, после чего подключает к себе как внешние процедуры :) И сразу двух зайцев с пулемета :)

>>Скажите, а для чего вообще нужна эта переносимость SQL-кода? Для
>>чего нужна проекту возможность работать с разными СУБД?
>>Для проекта вначале тщательно выбирается БД, удовлетворяющая всем
>>требованиям этого проекта. А потом вы уже пишите под эту БД,
>>используя _максимум_ предоставляемых ей возможностей.

Ну если пишешь небольшое специализированное приложение, то подобная логика на 100% верна. Однако! Однако есть программные продукты, окружение которых в работе на момент создания точно не известно. Или еще не известно кому их продадут :) А чтобы удачнее продавать продукт, нужно чтобы он не просто был хорошим, но и гибким. Ну возьмем случай, когда у потенциального покупателя везде стоит Oracle, а писали мы для DB2. Не всякий заказчик решится на покупку еще одной базы другого производителя. Потому и делают многие софтины с поддержкой нескольких типов БД.

Не совсем ясно высказал свою мысль, но думаю таки кто хотел, тот понял ;) Ночь на дворе, спать охота...

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

Да я вот заметел что большинство проблем на этом форуме вазникает изза недостаточно высокой квалефекации участников. Стыдно также писать с ошибками, всем надо срочно учить язык. Вот я даже имея богатый опыт работы с линуском ( более 2 месяцев ) и зная большенство современных языков програмиравания (потратил на их усиленное изучение более 3-х месяцев, отлично знаю C/C++, Java и другие) и то так самоуверенно не высказываюся как делают здесь многие ( совсем не абаснованно ). Вот мои основные тезисы и советы начинающим : Начинать изучение линукса нада с его изходных текстов ( желательно едра серии 2.4 ). Дистрибутив должен быть - Слака. Предварительно надо неделю потратить на изучение языка C, взяв книгу Кернигана и Ричи и упорно ее изучив. Научиться компилировать едро. Не ленится. Искать летиратуру. Я вот ездил в Москву(живу за 250 км от Москвы). После изучения исходных текстов (только едра) надо изучить лутший из лучших языков программирования - Перел. Перл являится нипроцедурным, а декларатевным языком. Это значит что программировать на нем гораздо быстрее чем на С и программы работают в 10-15 раз быстрее ( проверено мною ). После этого вы можете считать себя достаточно подготовленными для освоения других вершин познания.

P.S. В данный момент переписываю ядро линукса на Перле. Выбросил оттудова много лишнего. Получается намного компактнее и быстрее. Думаю на следущей неделе запустить.

Весь этот абзац надеюсь шутка :)

> Заголовок явно с претензией!

> Хотелось бы посмотреть на исходники программмы, как во всех пноральных тестах. И прогнать тесты с серверной и клиентской VM - как известно скорость их работы весьма отличается. И почему именно JDK 1.3, а не что-нибудь посвежее?

> ТщательнЕе надо, товарищи, тщательнЕе!

Есть и более интересные тесты: http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html http://www.ics.muni.cz/~makub/java/speed.html http://osnews.com/story.php?news_id=5602&page=3