Comments on TDelphi: будни Delphi блоггера: Delphi 2011: Fulcrum. Слухи и фантазии.

>Можно подумать, что мне больше делать нефиг, к...

2011-09-12T16:04:13.925+03:00

>Можно подумать, что мне больше делать нефиг, как только радовать вас очередными пруф-тестами :)

Я пошутил, не обижайтесь.
Но тесты, а вернее их резул. действительно интересны..)

Как Вам новая XE2 ?

> Ну что любитель С#, тесты какие нибудь появил...

2011-08-09T13:28:08.567+03:00

> Ну что любитель С#, тесты какие нибудь появились?

Можно подумать, что мне больше делать нефиг, как только радовать вас очередными пруф-тестами :)

> Или вы всё мерите быстродействие продуктов(качество) - количеством запросов(вакансий)
> на hh по языкам на которых они писались?

Я уже ничего не меряю и самому себе ничего не доказываю.
Я уже пишу на C#, радуюсь продуманной удобности ( по сравнению с Дельфиной ) и сильно напрягаюсь, когда приходится поддерживать старые тексты на архаичной Дельфине.

Ну что любитель С#, тесты какие нибудь появились? ...

2011-07-21T17:55:58.270+03:00

Ну что любитель С#, тесты какие нибудь появились?
Или вы всё мерите быстродействие продуктов(качество) - количеством запросов(вакансий) на hh по языкам на которых они писались?

Будут тесты ознакомьте...

> Можно 1-н объект создать, а внем милион запис...

2011-06-10T13:46:48.736+03:00

> Можно 1-н объект создать, а внем милион записей. Думайте поможет?

Не думаю, а знаю. Есть существенная разница в том один раз память большим куском в куче запросить или миллион.

> Нормальный тест, проведите свой если он не нравится.

Сами авторы в конце намекают на нереальность этого теста. Я вам тоже не первый месяц уже долдоню про его абсурдность. Чего вам еще?
И тесты я уже приводил. Будет время, приведу еще.

>>Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.

>О да.

А-то нет?!
Дельфистов все меньше. Молодежь не ведется уже.
Даже спецов по экзотическому Objective-C куда больше стало ( хотя это в основном и для Apple ).

> Почему об этом недостатке в хвалёном MSVC++ н...

2011-06-10T13:21:16.288+03:00

> Почему об этом недостатке в хвалёном MSVC++ никто не упоминает?

Это не недостаток. Это просто более низкий уровень доступа к пямяти. Дельфина поверх этого использует еще и свой механизм оптимизирующий запросы к системе.

На VС++ для подобного используются похожие алгоритмы и механизмы. Существует куча решений. Погуглите сами.
Кроме того можно воспользоваться small-bloсk heap ( раборает быстрее )

Короче, у вас есть выбор, а на Дельфи просто готовое решение.
Зато, у этого готового решения есть серьезные проблемы с мультипоточностью прои работе внутри DLL ( нарывался на 7-ке еще ). Может пофиксили уже, не знаю.

Дельфи - это все же прикладной RAD уровень с более узкими рамками по сравнению с VC++.
Поэтому и сравнивать его лучше с C# и Java ( по области основного применения )

>Вы сами себе противоречите. То вы говорите, чт...

2011-06-05T01:56:24.268+03:00

>Вы сами себе противоречите.
То вы говорите, что у вас нет возможности ставить крутые серверы типа Оракла у клиента и прикладывать к ним Админа для ваших небольших задач. То вдруг оказывается, что админ и сопровождение не причем, а только денег жалко. То у вас какие-то весьма специфические задачи, то вдруг они опять укладываются в схему клиент-сервер (был бы Оракл)...

Ни где не противоречу.
Понимайте 2-звенка, и 3-х звенка, конечно можно к 1-му свести и говорить что это весьма специфическая задача. Но в 3-х зв. произв. увеличивается за счёт уменьшения конектов к БД и Буфферизации частых запросов. Поэтому можно поставить Оракл и сделать большую нагрузку, а можно всё это разнести и обойтись например бесплатным FB.

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

Мои сожаления

>Одновременно создавать удалять и нова создавать миллионы "объектов" ( почеркиваю объектов ) в памяти для хранения однородных данных?

Можно 1-н объект создать, а внем милион записей. Думайте поможет?

>Вот именно.
При этом, похоже, что вы не знаете .NET среду или имеете весьма поверхностное о ней представление ( это видно из ваших постов ).
Но тем не менее пытаетесь найти причину, почему она ( по вашему мнению, конечно же ) отстойнее Дельфей на основании чьих-то не очень вменяемых тестов ( про миллион объектов ).

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

>Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.

О да.

>ИМХО: Лучше все же не ограничивать себя рамками изучения одного языка.

Согласен, пока только с изучением с использованием возникают проблемы...

>На нылых и плохо-оптимизирующих Паскалях, и в ...

2011-06-02T12:14:18.189+03:00

>На нылых и плохо-оптимизирующих Паскалях, и в управляемых средах .Net/Java такие серьезные "CPU & Memory eating" приложения, как правило, не пишут.<

Насчёт Memory eating... недавно сделал для себя открытие. Была необходимость реализации в DLL некоего алгоритма на С++ ранее написанного на делфях. Данный алгоритм подразумевал интенсивное выделение и освобождение кусков ОП различной длины. Цель перевода кода - устали ждать x64 копиляции в Delphi а памяти более 2-х гигов задействовать - очень заманчиво для нашего проекта (главное приложение уже переработали в среде MSVC++). Так вот, в ходе тестирования при средней нагрузке процесс не выдерживал длительного (не более часа) выполнения с новой DLL откомпилированной в среде MSVC++. При этом оперативной памяти задействовалось пару сотен МБ. В результате выяснилось, что приложение + ДЛЛ (напомню - реализованы в MSVC++) фрагментировали память в результате чего в определённый момент свободного куска нужного размера не находилось... Программируя больше на делфях я привык надеется что менеджер памяти за меня решает эту проблему... Чесно говоря, был очень удивлён, что в компании MS, зная что Windows сам эффективно не управляет распределением памяти, выпускает голый компилятр без средств управления её пользования. Данное заявление не голословно. Как раз пригодился недавно разработанный перехватчик API-вызовов. Через него проверил на вызов функции VirtualAlloc. На выполнение char* temp_buf = new char[8] приложение/длл попросит у системы 8 байт, что далеко не гуд. В модуле написанном на делфи память выделяеся кусками более 1МБ а затем она уде потом распределяется/собирается менеджером памяти.

После компильнул длл в Builder C++ - всё отлично заработало. Только вот более 2-гигов памяти мы так и неполучили по известным причинам. Писать свой менеджер памяти - дело трудозатратное.

Кстати, переработка менеджера памяти является ещё одним из тормозов перевода компилятора делфи на x64.

Почему об этом недостатке в хвалёном MSVC++ никто не упоминает?

ИМХО не думаю что в делфи он был реализован ради развлечения, попутно раскладывая пасьянс...Эффективное управление распределением ОП (оглядываясь назад) для многих моих приложений необходимо как воздух. Для тех приложений которые использует максимум несколько 10 Мб это значение может и не имеет.

И на последок - на паскале/делфи пишут очень серьёзное ПО, в т.ч. системное

> Я под "круче" понимаю быстрее и мощ...

2011-05-20T10:48:20.010+03:00

> Я под "круче" понимаю быстрее и мощнее, т.е за одно и тоже время обработает больше информации.
> Оракл + Не виндов.серв. + хорошее железо = решение которому сейчас врятле найдется конкурент.(Жалко что очень дорого)

Вы сами себе противоречите.
То вы говорите, что у вас нет возможности ставить крутые серверы типа Оракла у клиента и прикладывать к ним Админа для ваших небольших задач. То вдруг оказывается, что админ и сопровождение не причем, а только денег жалко. То у вас какие-то весьма специфические задачи, то вдруг они опять укладываются в схему клиент-сервер (был бы Оракл)...

> Об этом много интересных постов написано и во всех фигурирует одно название "Бесплатный сыр в мышеловке".

А вы сами из чисто альтруистических и научных целей программированием занимаетесь? ;)
Для малых и даже средних проектов зачастую вполне хватает и lite версий.
У меня, например, одна небольшая конторка уже пятый год на MSSQLExpress работают и ни одно из ограничений ( включая размер базы ) их пока не волнует.
А если контора разрастется, то не грех будет и заплатить за стартовую версию сервера.

> Тут не совсем-то о велосипеде речь идёт. Вот из всех СУБД...

Я, признаться, раза два прочел то, что вы написали, но так и не понял о чем вы..
Для того, чтобы оправдать то, что вы занимаетесь всей этой обработкой самостоятельно что ли?

> Задачи разные бывают. Если нужно отобразить 4 записи с БД в гриде, то повидимому это делать не нужно.

Одновременно создавать удалять и нова создавать миллионы "объектов" ( почеркиваю объектов ) в памяти для хранения однородных данных?
Это ИМХО бред, причем, безотносительно языка и среды.
По нормальному для этого просто выделяется участки/блоки/массивы памяти.

> да только эти 8% на компиляцию... А если взять не 1 функцию а 1 форму с кучей компонентов VCL+Дев.Эксп.Гриды+Стили и WPF+Дев.Эксп.Гриды+Стили, как вы думайте какие там будут 8%?

Погуглите про NGen ( стандартная утилита VS ). Даже никаких 8% ( хотя, по факту меньше ) на компиляцию тогда не будет.

> Я в отличии от Вас могу привести только голословные заявления...

Вот именно.
При этом, похоже, что вы не знаете .NET среду или имеете весьма поверхностное о ней представление ( это видно из ваших постов ).
Но тем не менее пытаетесь найти причину, почему она ( по вашему мнению, конечно же ) отстойнее Дельфей на основании чьих-то не очень вменяемых тестов ( про миллион объектов ).

Дело ваше, конечно. Только такие как вы рискуете скоро остаться в гордом одиночестве в качестве специалиста по дремучим системам.
ИМХО: Лучше все же не ограничивать себя рамками изучения одного языка.

Причем здесь "круче"/"не круче"...

2011-04-15T20:15:24.600+03:00

Причем здесь "круче"/"не круче" вообще?

Я под "круче" понимаю быстрее и мощнее, т.е за одно и тоже время обработает больше информации.

>Для начала, почему вы уперлись в Оракл?
Оракл + Не виндов.серв. + хорошее железо = решение которому сейчас врятле найдется конкурент.(Жалко что очень дорого)

>Существует куча беплатных SQL-серверов ( в том числе и встраиваемые решения ), которые не требуют ни мощной машины ни админа.

К сожалению я знаю только одно достойное решение - FB, все остальное пока не натом уровне. (MySQL - считаю платным)

>Кроме того, почти у всех коммерческих серверов есть бесплатные lite версии, так же годами работающие без админов на простеньких машинах.

Об этом много интересных постов написано и во всех фигурирует одно название "Бесплатный сыр в мышеловке"

>СПРАШИВАЕТСЯ, ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД?
Тут не совсем-то о велосипеде речь идёт. Вот из всех СУБД с которыми я сталкивался в работе (Оракл, MSSQL, FB) для обр. данных ХП испол. врем. или пост. таблицы которые физически находятся на HDD. И тут я боюсь сравнивать обработку на Delphi (или C#) (используя колек. объектов или ClientDataSet которые физически находятся в RAM) с обработкой на какой нибудь из СУБД. Здесь одинаковых условий нельзя создать, чтоб сравнить. Ну я полагаю что хреновеньком железе (обычный пень) Delphi будет в лидерах (хотя x64 уже на анонсировали, возможно это изменит ситуац. и в др нише). Да и язык имеет больше возм. чем TSql, PSQL или PL-SQL. Ну и понятное дело там где для данные это не 3 плоских таблицы и нужен SQL то только СУБД.
Вот интересный пост в тему http://www.delphinotes.ru/2011/03/n-plsql.html . Что делает мужчина для переброса в RAM. Ну и там у него вполне кода может выйти больше чем для аналог. решения на выс.уров. языке (правда которое не справится с его объёмами данных).

>При чем здесь необходимость одновременно создавать и удалять миллионы объектов?
Задачи разные бывают. Если нужно отобразить 4 записи с БД в гриде, то повидимому это делать не нужно.

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

да только эти 8% на компиляцию, где-то могут и больше где-то и меньше. А если взять не 1 функцию а 1 форму с кучей компонентов VCL+Дев.Эксп.Гриды+Стили и WPF+Дев.Эксп.Гриды+Стили, как вы думайте какие там будут 8%?

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

Я в отличии от Вас могу привести только голословные заявления, которые являются моим мнением и Вы можете с ним не соглашаться.

>В вышеприведённых комментариях есть опечатки. ...

2011-04-15T18:53:07.787+03:00

>В вышеприведённых комментариях есть опечатки. ...

Ну зря Вы так. Некая Дискриминация русского языка получается.

Анонимный >>> ***************************...

2011-04-12T15:17:17.840+03:00

Анонимный >>> *****************************************
Ну а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.
>>> ********************************************

Причем здесь "круче"/"не круче" вообще?

Давайте по порядку.

Вы сказали:
"у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом)."

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

СПРАШИВАЕТСЯ, ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД?
Тем более для небольшого заказа.

Анонимный >>> *****************************************
Ещё я вам секрет открою, в файлах могут хранится не только программы,...даже не запихивая в СУБД.
>>> ********************************************
А здесь в чем здесь разница между Дельфиной и C#. С потоковыми данными ( файлами ) они работают одинаково.
При чем здесь необходимость одновременно создавать и удалять миллионы объектов?

Анонимный >>> *****************************************
("Этот тест здесь неуместен" :)
Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто .... исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"
>>> ********************************************

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

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

И я нигде не говорил, что C# "круче". Я говорил свое мнение, что для огромного числа задач ( но не для всех ) C#+.NET удобнее Дельфины.

Анонимный >>> ***************************...

2011-04-12T12:36:07.372+03:00

Анонимный >>> *****************************************
Ну а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.
>>> ********************************************

Давайте по порядку.

Вы говорили, у вас "нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом)"

Спрашивается, а зачем вам вообще Оракл?

Вы знаете, что есть куча других SQL-серверов не требующих ни платы, ни мощных машин, ни админов.
Существуют встроенные и прилинкованные SQL- серверные решения.
Даже у Оракла и у MSSQL есть бесплатные lite версии, мощности которых для небольших задач хватает с большим запасом.

ЗАЧЕМ ИЗОБРЕТАТЬ СВОЙ ВЕЛОСИПЕД И ТРАТИТЬ НА ЭТО ДРАГОЦЕННОЕ ВРЕМЯ?

Анонимный >>> *****************************************
Ещё я вам секрет открою, в файлах могут хранится не только программы, документы, порно фильмы (с поркой), картинки, ..., но и данные которые можно обрабатывать. И Веб-служба может дать данные, которые тоже можно обработать, даже не запихивая в СУБД.
>>> ********************************************
Вы предпочитаете порнофильмы с поркой, что ли? :D

Ну хорошо, забудем про БД в данной задаче.
В вашем файле будет храниться произвольный поток данных. Чем здесь тогда Дельфина круче .NET?
.NET работает с потоками ровно также как и Дельфина.
При чем здесь одновременное создание и удаление миллионов объектов?

Анонимный >>> *****************************************
Аху... тест. Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто гавном исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"
>>> ********************************************
Во-первых, вы не правы.
Это очень показательный тест, который демонстрирует то, что качество машинного кода, получаемого на выходе после компиляции из .NET байт-кода очень и очень хорошее и вполне сравнимо с найтивными компиляторами.

Во-вторых, я привожу реальные тесты с исходниками. Которые каждый может проверить.
Вы же мне рассказываете бездоказательные сказки про каких-то заказчиков, которые просто "гОвном исходят" ( пишется через "О" ), при разнице 0,5c - 3c.
А тогда можно предположить, что, возможно, у кого-то просто руки не от туда растут? ;)

Вы конкретный пример пришлите, тогда и поговорим.

В вышеприведённых комментариях есть опечатки. &qu...

2011-04-11T20:10:00.062+03:00

В вышеприведённых комментариях есть опечатки.
"Полная хуйня." следует читать как "Вздор."
"Ахуенный тест" следует читать как "Этот тест здесь неуместен".

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

С уважением.

>Ну что же, понятно и, главное, что аргументиро...

2011-04-11T19:07:00.724+03:00

>Ну что же, понятно и, главное, что аргументированно :)

Ну а какие тут могут быть аргументы. Извините за грубую аналогию: Вас просят взять такси до Домодедово, в нуж. время чтоб успеть на самолет на Красноярск, Вы берете автобус до Красноярска, в 3раза дороже, аргументируя это тем что, Вам же туда же, это ни чем не отличается, даже круче.

Ещё я вам секрет открою, в файлах могут хранится не только программы, документы, порно фильмы (с поркой), картинки, ..., но и данные которые можно обрабатывать. И Веб-служба может дать данные, которые тоже можно обработать, даже не запихивая в СУБД.

>чистА поржать :)
Смотрите свой код и на результат его работы, я предполагаю у Вас найдутся "смешные" моменты

>Вычисление числа Пи... ~ 8%
Ахуенный тест. Жалко что он только для числа пи так работает. В реальных приложениях, пользователи(заказчики) просто гавном исходят когда у них откики 500Мс - 3000Мс. Или когда приложение "захлёбывается"

Анонимный >>> ***************************...

2011-04-08T12:20:28.444+03:00

Анонимный >>> *****************************************
Полная хуйня.
Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка), вам позно что либо понимать.
>>> ********************************************
Ну что же, понятно и, главное, что аргументированно :)
- "Полная хуйня!" и все тут.
- А мы как закачивали все данные на клиента так и будем работать по схеме фаил-сервер или на еще каком другом изобретенном нами "велосипеде".

Честно, говоря очень бы интересно было посмотреть на ваши поделки, где сервер используется лишь как хранилище и вся обработка на клиенте.
Так, что называется, чистА поржать :)

Анонимный >>> *****************************************
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.
>>> ********************************************
Думаю, вы не имеете дело такими задачами.
99% прикладных, учетных, офисных, внутрикорпоративных, и даже enterprise класса к таким задачам не относятся.

Если же вы хотите оценить реальную разницу в скорости конечного машинного кода ( Delphi vs .NET ), то вот вам небольшой вычислительный тест ( Вычисление числа Пи до 10000 знаков )
Исходники:
http://rapidshare.com/files/456439304/Pi_Competition.rar

На моем Core2Quad результаты такие:
Delphi: 3640ms
C#: 3970ms
Итого у Delphi конечный код быстрее на ~ 8%
Много это или мало решать вам.
На мой взгляд это вообще ни о чем в рамках учетных и прикладных задач, где больше времени тупит сам пользователь.

К слову, аналогичный алгоритм для Intel C++ компилятора дает прирост на ~ 20%. Так что для Real-Time решений тогда лучше уж выбирать хороший C++ компилятор, а не Дельфину.

Анонимный >>> *****************************************
Я поправлю, у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом). Я не так крут как парни из питера.
>>> ********************************************
??!! Причем здесь крутость этих парней?
Вы просто заикнулись про OracleForms. На что я вам ответил, что эту приблуду даже явные ораклисты уже сменили на C#.

И крутость здесь вовсе не причем. Почти любой сервер сейчас сопрягается с .NET с таким же успехом как и с Delphi.

>Боюсь, с вашим пониманием архитектур(С# интерф...

2011-04-07T16:22:58.656+03:00

>Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка)
Я поправлю, у меня нет возможности с каждым приложением придавать в комплекте(орокловый сервак и мощную машину с админом). Я не так крут как парни из питера.

>По пунктам:.... Полная хуйня. Боюсь, с вашим п...

2011-04-07T16:05:46.728+03:00

>По пунктам:....
Полная хуйня.
Боюсь, с вашим пониманием архитектур(С# интерфес - CУБД - рабочая лошадка), вам позно что либо понимать.

>.NET будет нервно курить в стороне практически только в одном случае, а именно когда время отклика может быть весьма и весьма критично.
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.

У нас девексовский ком. выбор даты поставил рекорд 3000мс каледарь открывался (за это время нативный DBX успевает засосать с сервока 100 000 записей, ~250МБ), и представляете .NET не курит в стороне в тек. задаче это приемлемо))

>Учи матчасть - WCF.
Вы меня не поняли , сейчас любая технология сможет скачать данный с веб-службы, вопрос только в объёме и скорости.

> И во всех этих вариантах архитектур, вы собир...

2011-04-07T01:22:19.257+03:00

> И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?

Похоже, что дот-нет и его реальные возможности вы не знаете.
Даже в многозвенках и тем более в веб сервисах Дельфина отстала капитально.
Учи матчасть - WCF.

Анонимный >>> ***************************...

2011-04-07T01:07:36.278+03:00

Анонимный >>> ******************************************
Дорой друг, Вам, с такими доводами и практиками в детсаде надо работать воспитателем – порщиком.
Есть же и другие архитектуры:
1) Где на БД по различным причинам (безопасности, производительности, ...) не создаются ХП(используют только как хранилища).
2) Где 3,4 звенка, и есть сервер приложений.
3) Где нет СУБД вообще., использ. файловые хранилища, либо веб-службы.
4) Или СУБД много и они гетерогенны и не имеют доступа к друг другу.
********************************************
По пунктам:
1) Для того чтобы реализовать большую часть обработки на сервере порой вовсе не нужно писать ХП. Например, можно обойтись последовательностью запросов и временными таблицами на сервере же. Надеюсь, это для вас это не секрет.

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

3) При чем здесь файл-хранилища?
Вы что весь файл в несколько гигов в память сразу грузите и на мелкие объекты его сразу разбиваете?
Если да, то вас действительно нужно пороть :)

А при чем здесь веб-службы, я вообще не понял.
Вы это для пущего веса что-ли сказали? ;)
Веб служба это по сути просто форма организации доступа к любым типам данных через XML.
Ну при чем здесь несколько миллионов создаваемых одновременно мелких объектов?

4) ???? Сами-то поняли к чему вы это сказали?
Вы что качаете миллионы записей в память из разных баз, преобразуете их в объекты и в памяти делаете безиндексный поиск, связку, или выборку по этим объектам?
УжОс-то какой!
Если да, то пороть для ума и немедленно! :)

Анонимный >>> ******************************************
И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?
>>> ********************************************

Я ответил, на абсурдность приведенных вами вариантов.
Хотя, все вышеперечисленные методы и подходы ( если только по уму ) вы абсолютно с таким же успехом можете забацать и на .NET, но при этом с гораздо большим удобством, чем на Дельфях. В этом-то, собственно, и фишка C#+.NET, которая всех в конечном счете и подкупает.

Так что не гоните пурги.
.NET будет нервно курить в стороне практически только в одном случае, а именно когда время отклика может быть весьма и весьма критично.
Т.е., когда есть разница между ( условно ) 10мс и 50мс в ответе на прерывание.
Но таких задач весьма не много.

Анонимный >>> ******************************************
Я думаю что для написания "морд" не обязательно пользоваться высокоуров. языками, попробуйте ОраклФормс посмотреть или подобные конструкторы.
>>> ********************************************

Даже многие партнеры Oracle и то уже слезли с ОраклФормс, поскольку это более громоздко, гораздо менее функционально, и менее быстро. Например, в Питере крупнейший поставщик решений от Oracle ( Leaves ) и тот уже морды на C# давно пишет.

Анонимный >>> ***************************...

2011-04-06T01:58:59.687+03:00

Анонимный >>> ******************************************

Миллионны раз без остановки читает инфу из БД и на каждую запись создает объект в памяти?!!!
Где у вас такая практика?
Я бы такого программиста выпорол бы. Тут и на Дельфи тормоза начнутся.

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

Тащить миллионы записей одновременно на клиента - ЭТО ОЧЕНЬ И ОЧЕНЬ ПЛОХАЯ ПРАКТИКА без относительно языка или архитектуры.
Таких программистов гнать надо в зашей.
>>> ********************************************

Дорой друг, Вам, с такими доводами и практиками в детсаде надо работать воспитателем – порщиком.
Есть же и другие архитектуры:
1) Где на БД по различным причинам (безопасности, производительности, ...) не создаются ХП(используют только как хранилища).
2) Где 3,4 звенка, и есть сервер приложений.
3) Где нет СУБД вообще., использ. файловые хранилища, либо веб-службы.
4) Или СУБД много и они гетерогенны и не имеют доступа к друг другу.

И во всех этих вариантах архитектур, вы собирайтесь "сосать" с дотнетом?

---

Я думаю что для написания "морд" не обязательно пользоваться высокоуров. языками, попробуйте ОраклФормс посмотреть или подобные конструкторы.

Анонимный >>> ***************************...

2011-03-24T11:58:34.968+02:00

Анонимный >>> ******************************************
Поздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
>>> ********************************************
Да, еще в догонку о реальных козырях Дельфи и найтивной компиляции:
Вашу великую .NET программу любой школьник может перевести в исходный код при помощи .NET Reflector
-> защита коммерческих проектов на C# весьма проблематична.
И только не надо мне рассказывать про Dotfuscator.
Во-первых, по тому, что при использовании Dotfuscator-а вы лишаетесь возможности нормального трэйсинга собственного приложения у клиента. А это очень плохо! Поскольку, я ни разу не верю, что кто-то пишет вообще без ошибок :)
Во-вторых, dotfuscator может и запутает логику, но в конечном счете не предотвратит относительно легкое нахождение места, где вы ограничиваете своего клиента количеством соединений или триал-дней.

В отличии от этого полноценный EXE-шник дебажить куда сложнее. Тем более при наличии в нем "хитрых запуток". Здесь уже для вскрытия вашей "дойной коровы" школьником зачастую не обойтись.

Поэтому, C# и .NET конечно великая вещь и запросто вытеснит Дельфину из всех "внутрекорпоративов", "мордо-писных" и тем более WEB проектов.
Но в коробочном секторе .NET - это все же не комильфо.
Вот если бы MS сделала бы нормальный оптимизирующий найтивный линкер, линкующий все в один найтивный EXE-шник - ВОТ ЭТО БЫЛО БЫ ДЕЛО!!!
( Кстати, был такой сторонний проект, но благополучно заглох по понятным причинам.)

А покуда это не так, программисты на С++, Delphi и прочем найтиве будут востребованы еще очень долго.

Анонимный >>> ***************************...

2011-03-24T10:34:59.292+02:00

Анонимный >>> ******************************************
Судя по ошибки у вас D2006, скаченный с торентов))
Я чегото сомневаюсь что у вас там проектов >2Гиг
>>> ******************************************
Не, это точно, что последние версии Дельфины порой валятся с идиотскими ошибками.

Например, у нас есть серьезный и большой проект на Дельфи ( контроллер спец.аппаратуры ) и на нем время от времени проявляются все эти ошибки.

Самая безобидная - нежелание переходить по ссылке ( ctrl+click). Лечится закрытием о открытием проекта в IDE.

Надоедливая - сумашедшее моргание контекстной подсказки. Лечится тем же.

Более серьезная - вывод ошибки о circular reference при компиляции там где ее реально нет.
Но проект большой и взаимное проникновение юнитов все же присутствует ( в разумных пределах ).
Лечится полным построением ( Build ) а не частичной компиляцией.

Еще более серьезные - после некоторого времени работы могут появляться внутренние ошибки или падение IDE с выводом идиотских ошибок.
Лечится перезагрузкой IDE.

Дельфи 2010 купленная и все апдейты установлены.

Анонимный >>> ***************************...

2011-03-24T10:18:13.536+02:00

Анонимный >>> ******************************************
Поздно. Очень поздно, непозволительно поздно. Настолько, что люди уже расчухали, что Delphi сурово отстал.
>>> ********************************************
Подверждаю, Дельфина отстала. Местами даже очень существенно в идеологическом и технологическом плане.

Но у Дельфины все равно остаются козыри в кармане. Как ни крути найтивная компиляция в один EXE-шник - это есть хорошо.

Чего бы там не звездели про быструю JIT компиляцию на .NET. По факту же большой проект может существенно притормаживать на загрузке, если ему только не делать найтивный образ NGEN-ом ( но и с NGEN-ом тоже не все так просто )

Дельфина более подходит для написания проектов, с более или менее адекватным временем отклика ( когда это важно ). Т.е. всякие там контроллеры и программы обслуживающие разную аппаратуру я бы не C# писать бы все же поостерегся.
К тому же виснет студия при отладке многопоточных С# приложений частенько ( что VS2008, что VS2010 ).
Да и MS сама честно предупреждает, что C# не стоит использовать в критичных по времени отклика приложениях.
В таких случаях они предлагают пользоваться старым добрым С++, но мы то с вами понимаем, к какому геморою это зачастую приводит ( в сравнении с Дельфи ).

Зато морды для БД, и прочую интерфейсную часть на C# писать ГОРАЗДО удобнее, чем на Дельфине. Это да.

Анонимный >>> ***************************...

2011-03-24T09:51:18.545+02:00

Анонимный >>> ******************************************

Ну а как Вам код, который читает с БД инфу и на каждую запись создает объект, после некой обработки... Разве это не тот же вариант, который часто используется на практике...??
>>> ********************************************

Миллионны раз без остановки читает инфу из БД и на каждую запись создает объект в памяти?!!!
Где у вас такая практика?
Я бы такого программиста выпорол бы. Тут и на Дельфи тормоза начнутся.

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

Тащить миллионы записей одновременно на клиента - ЭТО ОЧЕНЬ И ОЧЕНЬ ПЛОХАЯ ПРАКТИКА без относительно языка или архитектуры.
Таких программистов гнать надо в зашей.

> Судя по ошибки у вас D2006, скаченный с торен...

2011-03-24T07:27:42.846+02:00

> Судя по ошибки у вас D2006, скаченный с торентов))
Ну что за детский сад! Сказал же: XE, купленный.

> проектов >2Гиг
Выражение супер. выдает квалификацию (вернее, ее отсутствие) с головой.