Я понимаю, почему адепты дотнета искренне не понимают, зачем нужен перфоманс: вы просто дальше обычных корпоративных сайтиков ничего не видели, и не разрабатывали. Окей, расскажу.

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

Когда кому-то нужен этот продукт, он сначала шерстит рынок, и находит предварительно подходящие варианты. Потом на этапе предварительного эвалуэйшена откидывает откровенный шлак. Оставшиеся вендоры подвергаются тестированию. Как правило, с качественными характеристиками все более менее на одном уровне. Возьмите Thrift, Protobuf и Avro, и посмотрите на то, что они умеют. Этого за глаза хватает подавляющему большинству кастомеров. Поэтому наиболее интересным этапом отбора является количественное тестирование, когда юзеры начинают гонять данные и смотреть на следующие вещи:
- загрузку сети
- загрузку процессора
- скорость передачи полезной информации
- количество операций в секунду
- нагрузку на память.

И когда вы к ним придете со своим несчастным SOAP, и покажите результат в несколько раз хуже других, ибо даже дураку понятно, что XML будет работать медленнее практически всего, то ни про какие premarute optimization вы им даже заикнуться на успеете, так как с вами просто перестанут разговаривать, и выкинут из конкурса.

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

Так что не пишите ерунды про "берлоги" и "быстрый XML", вы тем самым выставляете себя дилетантами. Лучше расширяйте свой кругозор.
У того, чем сейчас занимаюсь я, цель простая - он должен порвать по скорости конкурентов, которых как минимум 4 штуки.

petalvikО! Стало быть, проект пишется на голом Си?Отнюдь. Еще один дилетантский миф, что все сверхбыстрое должно быть написано на сях. Код, который генерирует JIT в Java не смогут превзойти по скорости подавляющее большинство программистов C/C++. А если и смогут, то не в разы, а дай бог, что б на пару десятков процентов. Но это мы говорим про какую-нибудь процедурку. А когда у вас проект на десятки и сотни тысяч строк кода, то на этот выигрышь всем становится плевать, так как пока синики напишут соответствующий функционал, таки выжав дополнительные 10 процентов, джависты и дотнетовцы уже займут весь рынок, благодаря высокой скорости разработки.

Пипец, среди вашей тусовки есть хоть кто-то, кто не мыслит шаблонами?

Алексей КВ Java можно отключить контроль типов и границ массивов?Ерунду не спрашивайте. После ваших перлов про XML, вопросы про контроль границ массива выглядят смешно. В Java есть прямой доступ к памяти процесса через специальный утилитарный класс. Вызов операций чтения/записи этого класса после компилирования JIT-ом вырождается в одну единственную инструкцию mov. Поэтому если вы дошли до того, что вам проверки границ массивов начинают отравлять жизнь, то вы берете этот класс, и начинаете фигачить что-угодно и куда-угодно без каких-либо проверок.
Конкретно в моей задаче это не является узким местом. У меня другие узкие места - сеть, аллокации массивов, последовательная vs рандомная запись/чтение в/из MemoryStream, рефлекшн. Разумеется, у меня есть некоторое количество unsafe кода. И я уверен, что добавь я его еще больше, приложение станет работать еще быстрее. Но так как на данный момент я не уперся в это, я склон считать, что выигрыш от этого с учетом амортизации будет крайне и крайне невелик. Поэтому мне плевать на эти несчастные границы массивов. Но если надо будет - я от них смогу избавиться, как в Java, так и в .Net.

Arm79Так что вопрос в допустимой задержке. Коллеги по форуму хотят вам сказать, свеном, что для вашей задачи, ВОЗМОЖНО, вполне допустимо использование Xml и прочих высокоуровневых протоколов. Вы ведь не сказали, в какие рамки должны уложиться...Коробочный продукт, на основе которого кастомеры строят свои решения. Поэтому критерий только один - как можно быстрее. XML под этот критерий не попадает никоим образом.

hVosttКак я уже говорил, рассуждения на уровне детского сада, в отрыве от контекста конкретной задачи говорить, что «SOAP в несколько раз хуже других» — это заявление не мужа, а пацана со двора, который ещё не переболел максимализмом.
Желаю вам повзрослеть, и надеюсь когда-нибудь вам доведётся писать «коробочное решение для юзеров».Вам до сих пор неводмек, что у меня нет конкретной прикладной задачи. У разработчиков SQL Server есть прикладная задача? Нет, им надо написать максимально крутой SQL движок, что бы когда их будут сравнивать с Oracle, они показывали лучшие цифры, потому что изначально потребности и возможности кастомера неизвестны, так как неизвестен сам кастомер.
Идите и предложите разработчикам SQL Server хранить данные СУБД в XML. Ну а чо, диски же сейчас большие и дешевые!