Re[8]: jsdk.jar - .NET

Здравствуйте VladD2, Вы писали:

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

VD>Дык. Я... это в России живу. :shuffle: И все ее ограничения и/или радости на меня влияют. Вот IT (в смысле мужик) он тепарь буджуй, но все равно на писюках живет.
Только вот и дотнет и джава не в России и не для России разработаны. И оченивать их с этой позиции наверное не стоит.

VD>О вот ты и сам сказал ключевое слово "до определенного предела". Т.е. иногда проще софт поправить, а иногда жележку новую прикупить.
Так граничные условия существуют почти для всего. Но тенденция то.

VD>И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение...
Проще чем что? Стиральной машинкой вот управлять все же проще будет :)

VD>Ну, есть же заменитель.
Медленнее на порядок? Это уже не заменитель.

VD> В .Net есть почти все, что тебе нужно.
Увы нет.
VD> Кое чего нет. Ну, так не трудно дописать.
Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много :)

VD> Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности.
Да можно. Кто же спорит? Только вот лучше бы все же в System.Collections он был.

VD>Ну, с корбой нужно скорее сравнивать COM и CLR.
Ну CORBA это архитектура больше, COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает. Далее, к COM надо добавить LDAP сервер. Да и двоичный tlb и текстовый IDL сравнивать трудно.

VD>Но оба этих дела перекрывают по областям применения CORBA.
Да, но CORBA, о это ужасное слово, многоплатформенна.

VD>>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?
AVK>>И что?

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

VD> а ясного пути интеграции с сервисами ОС вообще нет.
Потому как ОС то разные.

VD> Все нужно писать на С через JNI.
Не все а платформозависимую часть. Она как правило совсем небольшая.

VD> Для .Net это делается на ура даже напрямую из C# или VB.Net, а на MC++ сожно тварить все что захочешь запаковывая результат в CLR-совместимые обертки.

VD>>>К тому же ты снова уветрываешся от ответа. COM — это не Win32. Ты сравни сложность работы с Win32.
AVK>>А ты сравни сложность работы скажем с so модулями? :)
VD>Не понял.
Объясняю. В *nix'ах dll'ек нет, там есть so. Ну так как? Многоплатформенность java — как ее достоинство так и недостаток. Как впрочем и одноплатформенность дотнета. Я потому и говорю — для каждого проекта надо выбирать свою технологию.

VD>Я говрю за себя, когда речь идет о пристрастиях. Межплатформная переносимость — это пристрастие. Ты веришь, что это спасительная волшебная палачка, я в то что это геморой, даже на Яве или Нэте. Вот и вся разница.
Нет. Я говорю что межплатформенность иногда все же нужна. Иногда, заметь, а не почти всегда.

VD>Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках.
А бывает с точностью до наоборот.

VD>Ну, и что связанный список нельзя отнести к 1 проценту? К тому же функциональность его можно воспроизводить другими методами, что ты и продемонстрировал...
Вот ты привязался к списку.

VD>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
Ну как бы объекты персистентные.
VD>Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто).
Не очень редко.
VD> Тут реализация на массиве будет эффективнее.
С чего это? Основная работа — впихивание в начало и вытаскивание с конца. А вот это то в массиве очень медленно. Мне бы Queue подошла, но вот выкинуть из середины я там не могу.

VD> Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее.
Нет, не будет. Потому как к самим объектам обращение не происходит. Собственно кеш хранится в хештаблице, очередь используется для контроля времени жизни объектов в кеше.

AVK>>Еще пример вспомнил — при обработке XML SAX приходится где нибудь данные накапливать а затем произвольным образом часть из них выкидывать.
VD>Так может DOM использовать.
Используй DOM, а документик возьми мегабайт эдак 20-30.
VD>И опять же встает вопрос о частоте произвольного и обычного выкидывания.
Обычное = 0. Произвольное = 100%.

AVK>>Я тебе пример привел когда связаный список на порядок(!) быстрее списка на основе массивов.
VD>Не факт. Это может быть плохая реализация. Да и пример бессмысленный. В осмысленном все может быть совсем по другому.
Ну не охота мне городить что то осмысленное. Я просто показал режим при котором это проявляется. Реально такой примерно режим и есть. Только позиция выброса каждый раз новая. Просто для этого пришлось бы еще LinkedList реализовывать.

VD>Надо бы сделать рукопашный линкед-лист и посмотреть на его скорость.
Если завтра время будет — попробую.

VD>>>Да я собственно не против исходников, но намного больше мне нужна хорошая объектная модель, быстрый код, хорошая поддержка, совместимость с моими старыми ранаботками, и т.п.
AVK>>Я где то говорил что все вышеперечисленное не нужно?

VD>А это уже я говорил, что перечисленное мною (по-моему) в .Net лучше. :)
Чем поддержка java хуже? И чем тебя не устроила ее объектная модель?

VD>Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная?
Не типизированная а by value. Разницу чувствуешь? Ты не там съэкономил.

VD> Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :)
Естественно. Просто я знаю как болезненно переносят array-списки добавление и удаление в/из начала и середины.

AVK>>Если понадобится — будешь и на нем писать.
VD>Ну, если понадобится, то конучно. Вот только очень не хочется. Я на нем уже в свое время по писал... с меня хватит.
Это да.

AVK>>Это так, не для спора, просто забавный пример извращений.

VD>Ты нас извращенцев не тронь. :)
Да я сам такой :)

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:

AVK>>3) В java добавят boxing/unboxing. Вот уж где действительно косяк полный, отсутствие out параметров перед этим просто меркнет.
VD>В смысле, что без него не удобно?
Не удобно это мягко сказано. В EJB к примеру по стандарту типы могут быть только объектными. Представь сколько гемороя делать boxing/unboxing int и Integer ручками. Оне конечно извращенцы и советуют делать первичные ключи символьными и длинными. Но как же это все по сравнению с int тормозит.

VD>Глупость говорят твои разработчики.
Не мои а java. Мои разработчики это мама с папой

VD>Это их отсутствие приводит к тому, что компилятор не может контралировать возвращаемую память. Ты сам можешь привести пример "опастности" [out]-параметров. Самый простой пример [out]-параметра это функция. Вернее ее возвращаемое значение. Что же Сан функции не запретил?
Функции возвращают копию в стеке. А out параметр может пройти через несколько функций. Источником ошибок может являтся примерно такой код

int outparam = 1;
Func1(outparam);
//do something with outparam
Func2(outparam);
//do something with outparam
Func3(outparam);
//do something with outparam
Func4(outparam);

Здравствуйте AndrewVK, Вы писали:

AVK>Нет, именно надоело.

И все же спор "Кластеры vs Мэйнфрэймы" ты проиграл.

AVK>Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.

Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам. Ну а обычные EJB ничем не отличаются от любого объекта .Net.

Что такое JAAS я не знаю.

AVK>Это пример. Причем не единственный. Еще раз кину списочек

Ну, давай по пунтам.

AVK>1) LinkedList
Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину.

AVK>2) RandomAccessFile

В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное?

AVK>3) MemoryMappedFile

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

AVK>Из API
AVK>1) JDO

Не уверен что правильно понимаю, что это. Поясни, плиз.

AVK>2) EJB

Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато. Возможно подобные технологии будут встроены в SQL-Сервер. В .Net есть так называемый типизированный набор данных который выполняет похожие функции. В любом случае ставка делается на отключенные наборы данных которые могут сериализоваться в XML и пердаваться на другие серверы и клиентам. По сути другое решение того же самого.

Обычные EJB ничем не отличаются от любого объекта .Нэт.

AVK>3) JAAS.

Что это?

AVK>А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть.

RMI — частная технология Сана. Большинство производителей делают ставку на CORBA/IIOP. И, по-моему, правильно делают. Если убрать "побочную особенность", то найти отилчий между любым объектом .Нэта и EJB я лично не смогу.

AVK>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.

Это же куда? Ты бы еще сказал быстрее.

Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно.

AVK>Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?

А чем тебя дата не устраивает? К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты. По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет. Ко всему прочему, в .Net можно использовать ActiveX-ы.

VD>>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.
AVK>Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь.

Думаю, если массивы писали бы мы, то реализация на массивах обгоняла бы линкед-листовую.

VD>>Ну, это как бы из критики вытекает.
AVK>Не надо пожалуйста за меня говорить. Ничего такого из моей критики не вытекает
Тем не менее ощущение создаетсяю.

VD>> Чувствуется, что ты на этот продукт обижен, что ли...
AVK>Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится.

На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?

Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации. Те же value-типы, дают мощьную экономию ресурсов и повышают скорость. Вот бы к ним еще десрукторы приделали.

VD>>Да из разговора видно, что работаешь... только вот это и странно, что вроде с выбором ты уже определился (или я ошибаюсь) но продолжаешь копать схожую технологию...
AVK>То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net

Ну, метания это тоже не здрово.

VD>> причем делаешь это заранее предвзято.
AVK>Нет, это твои личные впечатления.

Ну, может быть.

VD>> Я тоже могу много плохого про Нэт сказать.
AVK>Но будешь молчать? Это ли не предвзятое отношение?

А ты погляди остальные темы.

AVK>Я ведь и плохие моменты java тоже отмечаю.

А я вот этого ни разу не заметил.

Ткни носом, плиз.

VD>> Но общее впечатление положительное.
AVK>У меня тоже.

Ну, тогда того... по тише налетай. А то у мегя впечатление создалось, что ты не нашол пимпочки и давай крыть всю платформу...

VD>> Думаю, если они в следующей версии прикрутят шаблоны в C# и повысят производительность компилятора, то будет просто замечательно
AVK>Да много чего еще дорабатывать надо. А на производительность компилятора мне честно говоря на*№ать. В С# incremental compiling есть, а в условиях отсутствия хидеров работает он просто идеально.

Я имел в виду производительность получаемого кода. У меня AMD 1400 я тормозов не замечаю.

VD>> (вот еще бы вернули возможность создавать деструкторы для value-типов

...).
AVK>А нафига? Эти типы — нечто вроде объектных заменителей ... ну скажем record в паскале. Т.е. сложных типов данных. А деструкторы им как бы не к чему.

А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа...

AVK>Ну а отсутствие деструкторов у классов — да мешает. Но это цена которую приходится платить за GC и отложеное удаление.

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

Хотя, отложенные деструкторы все же есть, только от них никакого толку.

VD>>Не, ну, нормально. Может этот спор я начал?
AVK>Может я?
А кто же?

VD>> Я бы вот на 1С точно ничего делать не стал.
AVK>И опять у тебя все черно-белое. Сколько времени тебе понадобится чтобы написать на дотнете простенький складской учет?

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

AVK>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего.

Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать.

AVK> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.

Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет.

VD>> утопичны или настолько слабо реализованы, что меня не устраивает.
AVK>Таки на java очень много успешных проектов, больше чем на дотнет.

Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад.

Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения.

Ну, и ко всему эти успешные обычно не используют всех наворотов. С базами работают через JDBC и т.п.

AVK>Так что не так уж и утопично. Вобще — о вкусе устриц можно спорить только с тем кто их ел.

Да. Наверно ты прав. Вот я видел порядка 600 коммерческих приложений для автоматизации бизнеса и не одно из них не было написано на Яве. А судя по воплям Сана они все давно должны быть переписаны на Яве.

VD>> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы.
AVK>Ну так рассказывай про свои потребности.

Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее?

VD>> Мне ведь нужно соблюдать генеральную линию партии.
AVK>А кому нужно?

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

VD>> Нэт тоже предлагает свои решения но тут (если они меня не устраивают) я вижу как реализовать, то что мне нужно.
AVK>А что тебе нужно?

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

VD>> Короче, каждому свое. Я (пока) выбрал Нэт.
AVK>Для чего?

Ну, вкратце... небольшой такой прокт... нечно вроде 1С-а с человеческим лицом.

Подробности здесь http://www.rsdn.ru/forum/message.asp?mid=31446&only и на нашем сайте www.optim.ru (но там сей час машина барахлит).

VD>>Можно выбирать язык для разработки конкретного проекта на конкретной платформе, но когда речь идет о выборе платформы (а Ява и нет несомненно платформы), то выбрать нечто для конкретного случая очень тяжело.
AVK>Есть специальные люди для которых подобные задачи — один из основных вопросов профессиональной деятельности. И ценятся такие люди намного больше обычных программистов.

Дык. Это... я и есть тот кому выбирать приходится. Видишь... вот программисты рядом программируют, а я с тобой информацию обработываю.

VD>> Большинство людей сделают выбор один раз. И я их понимаю. Именно на смену платформы уходят немереные деньги.
AVK>Зачем на смену? Уж коли ты начал делать проект на какой то платформе — потом менять поздно. А вот начиная новый проект можно и нужно рассмотреть вопрос выбора платформы, с учетом не только чисто технологических факторов. Я конечно понимаю — для программиста куда проще выбрать одну платформу и всю жизнь на ней писать. Но увы — так не получится. Выбрал бы ты к примеру в свое время весьма передовой FoxPro.

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

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

AVK>Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь.

Да я и не спорю с этим, но переучиваться и переделывать все с нуля это две большие разнецы.

VD>> Что же мне молчать? Если бы ты начал Яву не по делу гасить, я бы тоже встрял. Конечно с меньшим энтузиазмом и знанием дела, но встрял бы.
AVK>И никого не гашу.

Так я от тебя Яву и не защищаю.

AVK>Увы, на данном этапе развития дотнета в России почти любой вопрос проще расковырять самому. Специалистов практически нет.

Ну, кое что можно и в росии раскопать. Вот на нашем сойте и на дотсайте на многие вопросы можно найти ответы. Да и янковские форумы не от кого не зкрыты.

AVK>Странно ты как то воспринимаешь. Вот собственно фраза(не твоя) которая мне не понравилась
IT>>Ну так вот прямо в двух словах вряд ли расскажешь. Если её с чем-то и можно сравнить, то скорее всего с Java. Но это естественно больше чем Java.
AVK>А теперь твои фразы
VD>>Если .Net станет перенасима хотя бы в серверном варианте, т.е. без клиентского интерфейса (WinForms), то у Явы пропадет последний фиговый листок, но тем кто выбрал .Net это будет по фигу.

Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то?

VD>>по сравнению с документацией от той же Явы MSDN — это рай.(MSDN имелся ввиду)

AVK>А вот где я кого то обвинял? До сих пор пытаюсь доказать что не все так однозначно. И ничего более. Все остальное — домыслы.

Т.е. ты не говорил, что MSDN бяка?

Здравствуйте DarkGray, Вы писали:

VD>>Заметь насколько быстрее IntArrayStack. Мой тест еще интересен тем, что в нем легко переставлять тесты местами. При тестах я компилировал все в релиз и пре-JIT-ил EXE-шник ngen-ом. Машина AMD1400 RAM 512.

DG>Не корректно сравнивать IntArrayStack с остальными, т.к. для IntArrayStack не вызывается функция new object() для каждой итерации

Это что же такого не корректного? Хотя да. Чтобы это сравнение было корректно в object нужно еще и занчение i запихать.

Здравствуйте AndrewVK, Вы писали:

VD>>Что доказать? То что ленив?
AVK>Нет, то что дотнет сыроват.

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

AVK>Ты вот пузырьковой сортировкой пользуешся? Это из той же оперы.

Пузырек на больших объемах не на пордок медленнее. Он в квадрат лезет. А тут линейная зависимость. Хотя в критичном месте я бы это терпеть не стал бы.

VD>> но времени выполнения того же теста, на том же железе не приводишь.
AVK>Как же так — я же привел. Плохо смотрел?

Ну, в том момент я этого постинга еще не видел.

AVK>Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь?

Ну, дык для полноты картины еще бы нашел, а то пляшем все от листа...

VD>>Ну, что же значит он лучше спроектирован.
AVK>А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?

Задачи он решает совсем маленькие, а форум нет. Ну, а спроектирован он на на пятерочку. Я его малость подправил, а то менять местами трудно... ;)

VD>> Так что если у тебя делается очень много действий, не факт что они все необходимы. По объему информации наши постинги явно перекрывают среднюю накладную. :)
AVK>Нет.

Да у тебя не накладные, а какие-то досье. :))

AVK>Да нельзя подобные задачи сравнивать. Я тебе потому и привел размер кода одной только проводки чтобы показать что форум и КИС абсолютно несравниваемы.

Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных. Да форум не самый сложный код. Но тревиальным его тоже не назавешь. Зато он держит 1000 посетителей в день котрые создают море соощений.

AVK>Переделки — да. Но не перепроектирование основ.

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

VD>> и то что систему рассчитанную на малое предприятие нельзя перенести на большое (при внезапном чдо-росте) путем копирования Явоского кода с одной машины на другую. Так что переносимость для внутрифирменных проектов нужна редко.
AVK>Зато можно еще на год-другой отложить безвременную кончину и этим съэкономить денежек. Впрочем опять мы в какой то оффтопик скатываемся. Давай завязывать на эту тему.

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

AVK>Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах.

Не поверишь, за все время сделал один сайт и 12 лет занимался автоматизацией предприятий. Начинал с продажи и внедрения чужих систем...

AVK> И переносить его на КИС не стоит. Но если ты занимался именно КИС — расскажи поподробнее, если конечно не тайна. Всегда полезно обменяться опытом.

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

AVK>Знаешь, я на тему серверов не хочу спорить. Давай все же ближе к дотнету. Я специально на остальное не отвечаю, ибо не интересно это никому здесь.

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

VD>>GC – это часть CLR.
AVK>GC — это технология прежде всего.

Это понятно, но в .Net она является частью CLR, а .Net? это как сказал IT, больше чем... Ну, и уж тем более больше чем CLR.

VD>> CLR – надстройка позволяющая создавать переносимые между языками бинарные компоненты,
AVK>Наврал я немножко. Не CLR я имел ввиду а MSIL и VM для его выполнения

О это две большие разницы. Вот MC++ может создавать код на MSIL выполняемый VM (вернее он не выплняется, а Джитится или даже Преджитится), но при этом может вообще не использовать CLR, т.е. ни GC, ни комон-типов, ...

VD>>SOAP – протокол удаленных вызовов через http и XML.
AVK>html здесь лишний.

Не, именно по http.

AVK>Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.

CG да, но MSIL спокйно будет работать. А про собак... тебе хуже будет если драйвер будет компилироваться именно для твоего процессора, прямо при установке в систему? Но до этого еще далеко.

VD>> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее.
AVK>Это я заметил с самого начала. И памяти кстати заметно меньше кушает.

Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше, да и родной код полглащает не моло.

AVK>>>А за других я бы на твоем месте не стал говорить.
VD>>Ты можешь привести конкретное место где я это делал?
AVK>Поскипал ты зря. "А вто я, IT и MS думаем по другому." — твои слова?

Ну, и где я за других говорил. Я цитирую их точку зрения. IT прямо в этом постинге тебе это сказал, а MS во всех пресрелизах.

VD>>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.
AVK>Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки.

Вот и было бы объективно, но искл бы бяки ты в Яве. И не сомневаюсь, что нашол бы. :)

AVK>1906
AVK>172
AVK>(напомню старые
AVK>1547
AVK>156)
AVK>Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно :( Хотя я догадываюсь почему такой эффект.

Странные у тебя результаты. У меря процентов 10 выигрышь. Что за щелезка?

VD>>Зато я заною как при том же алгоритме увеличить скорость еще на порядок. Нужно просто заменить object на int (родной тип).
AVK>Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать.

В одном случае объекты, а в другом int придется. Да и объекты в родных типах должны работать быстрее.

AVK>1890
AVK>172
AVK>То есть эффект = 0. Догадываешся почему?

А ты замени object на реальный тип объекта. И к тому, же в слудующий раз тебе может понадобится int, а через object он будет в 10 раз медленнее.

VD>> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.
AVK>Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности.

Ну, и в сем же здесь пропадут надежность или удобство?

Шаблоны контролируют типы во время компиляции, а виртуальные методы и object делают рантайм-проверки. На лицо одни недостатки. И вдобства не пропадают. Ну в скобках прийдется тип указать.

AVK> Ибо железки ныне дешевеют а труд программеров дорожает.

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

AVK>Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность.

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

AVK>Но в отличие от некоторых об этих временах совсем не жалею. Я не тебя имею ввиду, просто достал треп что мол программисты программы писать разучились. Сами что такое ассемблер представляют по книжкам и примерчикам — зато с апломбом доказывают что мол если бы не MS все программы были бы написаны на ассемблере, в крайнем случае на голом С, занимали бы 20-30Кб и работали бы со свистом на трешках.

Да это знакомо. И самое смешное, что такие рассуждения я слышал от известных и уважаемых людей.

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте VladD2, Вы писали:

VD>>Стек действительно несколько быстрее.
AVK>Который?

Родной. .Net-овски. Да возьми мой вариант и по переставляй местами функции... сам все увидишь.

VD>> К тому же можно задать капасити, чтобы не фрагментировать память.
AVK>Кому? Я честно говоря не понял. Stack или ArrayStack?

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

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

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте VladD2, Вы писали:

VD>>Результаты теста зависят от очередности (из-за фрагментированности памяти). К тому же я бы задал капасити заранее. Это уменьшило бы фрагментацию.
AVK>Неа, не угадал

AVK>Это GC родимый шуткует. Миллион объектов — это много и во втором цикле запускается GC, прибивая память за предыдущим. Я поправил — теперь все харашо.

Ну, тогжа запусти мой вариант посмотри на результаты...

VD>>Заметь насколько быстрее IntArrayStack.
AVK>Э какой хитрый. Ты Capacity делаешь сравнимым с количеством хранимых объектов. И твой список вырождается в массив.

Так он у всех такой. Думаю, если уменьшить его, то все равно расклад отстанется прежним.

AVK>Да еще и кастинг выкидываешь за счет хранения простых типов.

Ну, а ты что же хочешь чтобы производительность из воздуха бралась? Тебе этот кастинг нужен? Мне нет. На С++ только так все и работают. И скорось на уровне, и ошибок с кастингами меньше.

AVK> Плюс отсутствуют затраты на new.

Ну? Вот и подумай на фига козе баян. Зачем нюь для int? А это ведь самый распространенный тип...

AVK>Плюс используются типы by value и нет выделения памяти в куче и GC.

Ну? Так того и добивались, а с обжектом ты плучаешь весь этот кайф, а он ведь тебе не нужен.

AVK> За что тогда боролись?

Так за типобезопастность и производительность!

AVK> Увы, чаще всего надо хранить объекты и возможный максимальный размер может быть сильно больше чем среднерабочий.

Ну, при неаравильном приектировании конечно. А при правильном лучше хранить структуры или простые типы. В общем и целом, чем мешьше памяти в куче выделяется, тем лучше. GC это правило ослобляет, но не снимае. В сложных случаях GC проигрывает обычной куче.

AVK>А если это не так — проще использовать массивы. Короче — я переделал твой класс под object и задал начальный Capacity = 1000.
AVK>было для ArrayList 516. Для переделанного под object IntArrayList 391.

Видишь даже с совершенно не производительным хранением информации мой вариант быстрее.

Но ведь основной расчет тут делался на отбрасывание нунужных полиморфностей.

AVK>Аналогично релиз. ngen эффекта не дает. AMD XP 1466 512 памяти.

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

Здравствуйте AndrewVK, Вы писали:

AVK>Только вот и дотнет и джава не в России и не для России разработаны. И оченивать их с этой позиции наверное не стоит.

Ну,я где живу. там и оцениваю. :) Ну, а про то, что IT в Америке обитает, ты надеюсь понял. Ты то сам вроде тоже в России обитаешь...

AVK>Так граничные условия существуют почти для всего. Но тенденция то.

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

VD>>И аксиом тут никаких нет. Есть только конкретные жизненные условия. А управляемость... вещь которую измерить турудно. Я вот считаю, что управлять ПО созданого для Windows и в его духе проще, но это мое личное мнение...
AVK>Проще чем что? Стиральной машинкой вот управлять все же проще будет :)
Проще чем софт который создается для других платформ и тем более чем софт создающийся как переносимый и/или масштабируемый.

VD>>Ну, есть же заменитель.
AVK>Медленнее на порядок? Это уже не заменитель.
Ну, тебе показал, что технологии абстракции данных в CLR и Яве тоже медленнее на порядок, но ты же из-за этого не откажешься от них?
Причем, в твоем случае нужно протянуть руку и написать свою реализацию, а вот полиморфизм через object & виртуальные методы — это приговор (пока не появятся шаблоны).

VD>> Кое чего нет. Ну, так не трудно дописать.
AVK>Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много :)

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

VD>> Скорости универсальной реализации хватит на 90% случаев, а в тонком месте можно всунуть свою (заточеную на конкретные условия) реализацию. Как я уже доказал это может дать значительный выигрыш производительности.
AVK>Да можно. Кто же спорит? Только вот лучше бы все же в System.Collections он был.

Добавь. ;)

VD>>Ну, с корбой нужно скорее сравнивать COM и CLR.
AVK>Ну CORBA это архитектура больше,

Не... спецификация. :)))

AVK>COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает.

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

AVK>Далее, к COM надо добавить LDAP сервер.

Это еще зачем?

AVK>Да и двоичный tlb и текстовый IDL сравнивать трудно.

А зачем их сравнивать. Вон в нет эту идею еще дальше расширели. А маньяки от корбы до сих пор кричат, что видте ли это не гибко. Это биче гибкого. Просто один раз нужно разобраться. Сгенерить IDL по tlb или создать файл C# или VB.Net по сборке проще просого. А вот то, что в CORBA-е до сих пор нет объектной модели — это явный минус. В конце концов CORBA-а все равно приобретет многие четры COM-а. И я ничего плохого в этом не вижу. Как и в том, что Ява возьмет черты Шарпа.

VD>>Но оба этих дела перекрывают по областям применения CORBA.
AVK>Да, но CORBA, о это ужасное слово, многоплатформенна.

Да, и DCOM многоплатформный. Просто все кому этого не хочется об этом и не знают. Ну, правда денег стоит, но и CORBA стоит. Вот только большинству людей COM не нужен не других платформах, да и корба тоже...

VD>>>>Может сравним производительность и простоту работы с COM-ом через этот бридж и в Нете?
AVK>>>И что?

И выйдет, что в Нэт это продуманно и легко, а в Яве не очень, то.

VD>>И то, что для Явы все это будет геморой,
AVK>Так ествственно, технология то ждля нее неродная и вобщем то необязательная.

Ана для меня обязательная и для многих тысяч программистов.

VD>> а ясного пути интеграции с сервисами ОС вообще нет.
AVK>Потому как ОС то разные.

А мне пофигу. На любой ОС есть аналог DLL и сам разберусь, что мне в них нужно. Просто дайте мне спокойно делать, то что я хочу, а не то что получается.

VD>> Все нужно писать на С через JNI.
AVK>Не все а платформозависимую часть. Она как правило совсем небольшая.

Она как правило есть. И как правило выливается в гемморой.

VD>>Не понял.
AVK>Объясняю. В *nix'ах dll'ек нет, там есть so.

Ну, и что? А это знаю. Что мешает мне использовать на Линуксе одно, а на Виндузе другое?

AVK> Ну так как? Многоплатформенность java — как ее достоинство так и недостаток. Как впрочем и одноплатформенность дотнета. Я потому и говорю — для каждого проекта надо выбирать свою технологию.

Думаю, что MS обязатеьно сделает показательную портацию .Net на какой нибудь Mac OS 10. :) Про Моно ты надеюсь уже слышал?

VD>>Я тебе уже говорил, что у нас есть проект в котором 300 000 строк кода и в нем не разу не исползовлся связаный список? По этому и спрашиваю. Обычно есть более эфективные решения, чем использование связаных списков. Выигрывая в скорости обновления ты безнадежно проигрываешь во все остальных скоростных корактеристиках.
AVK>А бывает с точностью до наоборот.

У кого? У нас небыло... Не, ну, в жизни все бывает...

VD>>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
AVK>Ну как бы объекты персистентные.

А! Замечательная технолгия... для загрузки процессора и свободной памяти. Вот только тебе пожалуй нужно не кэш, а пул создавать. Проще читать данные и ассоциировать их с инстансами. К тому же объекты ининтифицируются по ID, а их нужно не в связанных списках ранить, а в map-ах.

VD>>Во-вторых, ты проанализируй свои слова "Иногда их нужно было выпихнуть". Ключевое слово "иногда", т.е. викидывание из середины прозводится редко (это, кстати, встречается очень часто).
AVK>Не очень редко.
Да ну тебя. Тогда пиши: "Объекты постоянно выпихиваются и иногда...".

VD>> Тут реализация на массиве будет эффективнее.
AVK>С чего это? Основная работа — впихивание в начало и вытаскивание с конца. А вот это то в массиве очень медленно. Мне бы Queue подошла, но вот выкинуть из середины я там не могу.

А Queue в Нэте тоже на массиве сделана. Представь себе змейку... вытаскиваешь элемент с конца... указатель на голову сдвигается вперед, а на его метсо можно будет поместить хвост (при добавлении новгог элемента). Если места не хватает (хвост наезжает на голову), массив расширяется, если хватает, то протсо бегаем по кругу...

VD>> Задаш капасити по больше и вперед. Кстати, если объекты одного типа (унаследованы от такового или реализуют один интерфейс), то лучше сделать список объектов именно этого типа. Это будет работать куда быстрее.
AVK>Нет, не будет. Потому как к самим объектам обращение не происходит. Собственно кеш хранится в хештаблице, очередь используется для контроля времени жизни объектов в кеше.

Я уже говорил, что очередь (в отличии от связанного списка) реализуется на массиве без потерь производительности? :) А ускорение будет хотя бы из-за того, что вместо object будет храниться менее абстрактная ссылка, меньшего размера.

VD>>Так может DOM использовать.
AVK>Используй DOM, а документик возьми мегабайт эдак 20-30.

Ну, 30 это уже не документик, а база данных и довельно не маленькая. Прайс книжного магазина (Интернетного) занимает 12 мег. Да и выдержит он в лет. 30 мег для современного компьютера это фантики, ну а делее нужно переходить на БД.

VD>>И опять же встает вопрос о частоте произвольного и обычного выкидывания.
AVK>Обычное = 0. Произвольное = 100%.

ТAVK>Чем поддержка java хуже?

Да тем, что книг по Яве и Нэту на русском примеро онинаковое количество, а Нэту всего месяц. Тем, что по нету создано сотни форумов за это время. Тем, что документация первой версии Нэта удобнее и понятнее, чем n-ной Явы. Тем, что вместо зачастую пустого ЯваДок, а имею MSDN и возможность качественного поиска по нему.

ТAVK>И чем тебя не устроила ее объектная модель?

Ну, ты посмотри CodeDom, Emit, дезайнеры типов, броузер свойств, да и сами свойства которые есть в EJB, но нет в самой Яве, и т.п. И покажи аналоги в Яве. А то может я просто чего не знаю?

VD>>Так у увсе разные запросы. Ты вот видел насколько быстрее типизированная коллекция, чем универсальная?
AVK>Не типизированная а by value. Разницу чувствуешь? Ты не там съэкономил.

Не, не чувствую. Я разницу в скорости чувствую. Мне 4 байта хранить нужно. Из солидарности с апологетами плиморфизма я этого делать не намерен.

VD>> Можешь глянуть как тормозить универсальная сортировка по сравнению с типизированной... А иногда бывают места где производительность нужно... и очень. Ты вот сам хочешь ведь не именно линкед-лист, а чтобы по быстрее было. :)
AVK>Естественно. Просто я знаю как болезненно переносят array-списки добавление и удаление в/из начала и середины.

Это как спроектируешь. У нас есть масмив который спокойно переносит. Он по кластерному принципу построен. А удаление из конца массивы (динамические) всегда переносят легко.

Здравствуйте AndrewVK, Вы писали:

AVK>Функции возвращают копию в стеке. А out параметр может пройти через несколько функций. Источником ошибок может являтся примерно такой код
AVK>

AVK>int outparam = 1;
AVK>Func1(outparam);
AVK>//do something with outparam
AVK>Func2(outparam);
AVK>//do something with outparam
AVK>Func3(outparam);
AVK>//do something with outparam
AVK>Func4(outparam);
AVK>

Ну, и в чем проблема? Кстати в шарпе он бы виглыдел так%

int outparam = 1;
Func1(out outparam);
//do something with outparam
Func2(out outparam);
//do something with outparam
Func3(out outparam);
//do something with outparam
Func4(out outparam);

Т.е. явное указанеи out.

А эквивалентно это этому:

int outparam = 1;
outparam = Func1();
//do something with outparam
outparam = Func2();
//do something with outparam
outparam = Func3();
//do something with outparam
outparam = Func4();

В чем опасность не понятно!

Здравствуйте VladD2, Вы писали:

AVK>>Пятый раз говорю — плевать мне на LinkedList, я его в качестве примера привел. Я нигде не говорил что именно без него я жить не могу. Это ПРИМЕР, понимаешь?
VD>Ну, дык для полноты картины еще бы нашел, а то пляшем все от листа...
Мне третий раз сюда один и тот же списочек писать?

VD>>>Ну, что же значит он лучше спроектирован.
AVK>>А тест мой раз в сто наверное меньше чем местный форум. Наверное еще лучше спроектирован?

VD>Задачи он решает совсем маленькие, а форум нет. Ну, а спроектирован он на на пятерочку. Я его малость подправил, а то менять местами трудно... ;)
Так и у процедуры проведения накладной тоже задачи побольше чем у форума.

AVK>>Нет.
VD>Да у тебя не накладные, а какие-то досье. :))
А ты думал. Я же тебе говорю — не все так просто как кажется со стороны.

VD>Так в чем принципиальная разница? И там и там OLTP, и там и там накопление промежуточных результатов и структурезация данных.
В форуме еще и OLAP есть? Разбивка на партии? Проверка и коррекция остатков и оборотов? Контроль кредитов, договоров? Погашение долга? А там еще много чего есть.

VD> Да форум не самый сложный код. Но тревиальным его тоже не назавешь.
Так я и не говорю что он тривиальный. Но форум я могу написать скажем за недельку, не особенно напрягаясь. А вот нормальный оперативный учет уже несколько сложнее.

AVK>>Да не хочу я пиписьками меряться. Просто судя по твоим словам основной опыт у тебя в веб-проектах.
VD>Не поверишь, за все время сделал один сайт и 12 лет занимался автоматизацией предприятий. Начинал с продажи и внедрения чужих систем...
Каких, если не секрет?

VD>Ну, не хочешь так не хочешь, но про то что не интересно — это ты зблуждаешся.
Ау, кому нибудь это интересно? :)

VD>>>GC – это часть CLR.
AVK>>GC — это технология прежде всего.
VD>Это понятно, но в .Net она является частью CLR, а .Net? это как сказал IT, больше чем... Ну, и уж тем более больше чем CLR.
Я где то говорил что это не так?

VD>>>SOAP – протокол удаленных вызовов через http и XML.
AVK>>html здесь лишний.
VD>Не, именно по http.
Как минимум часто еще SMTP часто используется. А вобще протокол может быть любой.

AVK>>Да я же не говорю что применить нельзя. Просто MSIL, CG, далее по списку для драйверов — ну примерно как для собаки пятая нога.

VD>CG да, но MSIL спокйно будет работать.
Будет. Но нафига он там?

VD> А про собак... тебе хуже будет если драйвер будет компилироваться именно для твоего процессора, прямо при установке в систему?
А при чем здесь MSIL? В *никсах вон так и поступают, без всякого IL. Или ты имеешь ввиду компиляцию IL в нейтив код — так увеличение производительности от этого — пока декларация как для дотнета так и для джавы.

VD>>> В Яве этот слой отсутствует как класс. И именно это (не драйверы, а открывающиеся возможности) меня и подкупает. Ты уже заметил, что не универсальный код написанный на .Net работает быстрее.
AVK>>Это я заметил с самого начала. И памяти кстати заметно меньше кушает.
VD>Мои экспременты показывают обратное. Скачай примеры от шустрика посмотри. Ява жрет не меньше,
Так я и говорю что больше она жрет.

VD>>>Так и мне не кажется. Но моих рассуждений, это не отрицает. Хотел бы я посмотреть, что бы ты сказал если .Net ты увидел бы раньше Явы? Думаю твое отношение был бы совершенно иным.
AVK>>Вряд ли. Технологии я стараюсь оценивать объективно. Кстати после java очень легко воспринимаются многие дотнетовские фишки.
VD>Вот и было бы объективно, но искл бы бяки ты в Яве. И не сомневаюсь, что нашол бы. :)
А чего их искать? Их там есть. Я тут даже упоминал некоторые. Могу еще сказать что в самом языке сильно не хватает свойств и типов-перечислений (это для меня основной недостаток именно языка).

AVK>>1906
AVK>>172
AVK>>(напомню старые
AVK>>1547
AVK>>156)
AVK>>Вот такие вот пирожки с котятами. До этого я еще кое что с ngen и без мерял — эффект был = 0 (на 2 бете еще). А теперь вобще все грустно :( Хотя я догадываюсь почему такой эффект.

VD>Странные у тебя результаты. У меря процентов 10 выигрышь. Что за щелезка?
Я уж вроде писал. AXP 1700+, 512 DDR

AVK>>Э нет — так низзя. Нафига мне int хранить? Мне объекты хранить нужно. Впрочем опять же — никаких проблем попробовать.
VD>В одном случае объекты, а в другом int придется. Да и объекты в родных типах должны работать быстрее.
а тип object для экземпляров object не родной?

VD>А ты замени object на реальный тип объекта.
Так в тесте object как раз и есть реальный тип объекта. Ладно, небольшой примерчик

using System;
using System.Collections;

class ArrayStack {
 private ArrayList al = new ArrayList();
 public void Push(object obj) {
  al.Add(obj);
 }
 public object Pop() {
  object obj = al[al.Count-1];
  al.RemoveAt(al.Count-1);
  return obj;
 }
}

public class Test {
 private const int ITER_COUNT = 1000000;

 public static void Main() {
  ArrayStack ars = new ArrayStack();
  int st = Environment.TickCount;
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(new object());
   ars.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);
  GC.Collect();

  ars = new ArrayStack();
  st = Environment.TickCount;
  object obj = new object();
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(obj);
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Push(obj);
   ars.Pop();
  }
  for(int i = 0; i < ITER_COUNT; i++) {
   ars.Pop();
  }
  Console.WriteLine(Environment.TickCount-st);
  GC.Collect();
 }
}

Результат
1132
480

Вот он твой эффект. А для int еще и нет конролируемых ссылок.
VD>И к тому, же в слудующий раз тебе может понадобится int, а через object он будет в 10 раз медленнее.
Ну не в 10 раз — но таки да, для int можно. Только объекты все же почаще используются.

VD>>> Вот CLR и Ява тем и плохи, что полиморфность в них достигается за счет использования виртуальных методов и типа object. На C++ я бы написал шаблон и он бы дал лучшую производительность.
AVK>>Вот о чем я и говорю — лучше пожертвовать производительностью в угоду удобству и надежности.
VD>Ну, и в сем же здесь пропадут надежность или удобство?
В чем удобство полиморфности? В большей универсальности кода.

VD>Шаблоны контролируют типы во время компиляции, а виртуальные методы и object делают рантайм-проверки. На лицо одни недостатки. И вдобства не пропадают. Ну в скобках прийдется тип указать.
На шаблонах рефлекшн не будет работать. Но это так. А вобще использование шаблона для объектов в плане производительности ничего не даст. Шаблон просто привнесет дополнительный контроль типов.

AVK>> Ибо железки ныне дешевеют а труд программеров дорожает.
VD>Во блин. Снова за свое. То ему просадка на порядок из-за отсутсвия листа мешает, то он плюет на тот же порядок в том же случе. Ты подумай, если сложить тот порядок с этим то получится уже сотня.
Не, использование связаного списка дает повышение производительности практьически бесплатно, а вот перепроектирование системы — нет.

AVK>>Это тенденция однако. Хотя я хорошо помню времена XT-шек когда основной ресурс был — время процессора и приходилось писать большие куски на ассемблере чтобы получить, нет, не большУю, просто приемлемую производительность.
VD>Так времена не изменились изменились задачи. У меня всегда программы работали на пределе железа, если появлялось новое железо, то для него сразу же поялялись новые задачи. Именно по этому я понимаю твое стремление найти более производительный способ работы с данными, и именно по этому не понимаю рассуждений про железки.
А про железки это потому что мне приходится не только программить, но еще и заниматься эксплуатацией. И купить железку обычно куда как проще и дешевле нежели переписывать готовый код. Я могу конечно посадить программера, он за два-три месяца мне процентов на 10% тот же модуль перепроведения ускорит. Но за те же деньги я куплю еще один серверок и через 2-3 дня у меня все заработает быстрее на те же 10%, если не быстрее. Вот о чем я пытаюсь сказать. А то что иногда все же приходится кардинально все переделывать — да, такое тоже вполне возможно. У меня вот сейчас старый оперативный учет по одной фирме как раз полностью выкидывается, ибо проще сделать с нуля новый чем дорабатывать старый. Но он отработал 5 лет и вполне себя оправдал. А если бы я оставил старый серверок, на котором он первоначально работал — уже через 2 года мне бы пришлось думать об увеличении быстродействия. Как ты считаешь — 2 штуки, отданые за серверок за 3 года себя оправдали?

VD>Да это знакомо. И самое смешное, что такие рассуждения я слышал от известных и уважаемых людей.
Тут одно из двух — либо человек вобще нифига не понимает и говорит с чужих слов, либо его знания программных технологий так и остались десятилетней давности. Я помню как на БК-0010 приходилось байты экономить. Но это же не повод делать то же самое сейчас? Кого сейчас волнует — 400К или 4М занимает exe?

Здравствуйте VladD2, Вы писали:

AVK>>Я сказал что дотнет еще сыроват и привел списочек чего лично мне в нем не хватает.

VD>Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам.
Это что же за такие принципиальные причины?
VD> Ну а обычные EJB ничем не отличаются от любого объекта .Net.
Обычные это какие? Есть четыре типа бинов
1) Stateless session
2) Stateful session
3) Entity BMP
4) Entity CMP
Только для первых аналогом может быть WS. Вторые можно на базе WS съэмулировать. А вот 3 и 4 — это уже проблема. Особенно 4.

VD>Что такое JAAS я не знаю. :(
Java Authentication and Authorization Service

AVK>>1) LinkedList
VD>Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину.
Не эмулируется а пишется целиком ручками

AVK>>2) RandomAccessFile
VD>В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное?
Ну как минимум нужно еще getLength() и setLength(). Плюс стримы оптимизированы под последовательный доступ.

AVK>>3) MemoryMappedFile
VD>Не имеет смысла, так как в предалах лотальной машины все данны всегда передаются через мапленную память, а с точки зрения файла это всего лишь метод доступа.
Иногда очень удобный. Не критично но в некоторых случаях время экономит.
VD> Возможно обычный файловый доступ реализован через него. Так что это лишнее выпячивание алгортмов. В конце концов если уж пойти на принцип, в Нэт можно за пять минут описать функции работы с мапнутыми файлами ОС и испльзовать их.
Можно, кто спорит. Но это уже не то.

AVK>>Из API
AVK>>1) JDO
VD>Не уверен что правильно понимаю, что это. Поясни, плиз.
Java Data Objects
цитата из спецификации
JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native Java programming language objects

AVK>>2) EJB

VD>Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато.
По поводу производительности я уже говорил — это не самое главное. Да и подобное преобразование все равно делать приходится очень часто. Все дело в уровне абстракции и количестве ручной работы. Не устраивают CMP — есть же еще и BMP. Пиши в базу ручками наздоровье.

VD>Возможно подобные технологии будут встроены в SQL-Сервер.
Ну xml то он уже хранит. А это по сути уже почти что объекты.

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

AVK>>А стейтфул для EJB это побочная особенность. Да и сравнивать с WS глупо — EJB это намного больше. Аналог WS в java это RMI. Хотя в java и WS есть.
VD>RMI — частная технология Сана. Большинство производителей делают ставку на CORBA/IIOP. И, по-моему, правильно делают. Если убрать "побочную особенность", то найти отилчий между любым объектом .Нэта и EJB я лично не смогу.
Автоматические транзакции, в т.ч. и распределенные. Умное кеширование везде где только можно. Entity бины. Меппинг объектов в базу, полуавтоматически и автоматически. EJB надо сравнивать с servviced components а не с дотнетовскими объектами.

AVK>>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.
VD>Это же куда? Ты бы еще сказал быстрее. :) Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно.
Это тебе так кажется. По незнанию. На самом деле очень удобно. И от MVC в отличие от нета не отходит.

AVK>>Во, кстати, еще вспомнил — почему в этих самых формсах нет обычного грида, без всяких там Data? Тоже ручками писать надо?

VD>А чем тебя дата не устраивает?
Нафига мне для редактирования данных в табличке ADO.NET тащить? Это уже пушкой по воробьям получается.

VD> К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты.
Гы.
VD>По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет.
Ты JTable видел? Особенно в 1.4. Все эти дельфовые и VB-шные гриды по сравнению с ним как раз детский лепет и есть.

VD>>>Ну, это уже зависит от реализации. Будет время можно будет поэкспериментировать.
AVK>>Так LinkedList и ArrayList только реализацией и отличаются. Впрочем, сколько не экспериментируй — отставание на порядок ты не исправишь.
VD>Думаю, если массивы писали бы мы, то реализация на массивах обгоняла бы линкед-листовую.
Про списки я другой топик заведу.

VD>>> Чувствуется, что ты на этот продукт обижен, что ли...
AVK>>Не правильно чувствуется. Если говорить о моих чувствах то дотнет мне нравится. :) На данный момент главное от него ощущение — это как пересесть со спортивной машины(java) на шикарный представительский мерс(дотнет). Аналогия понятна?

VD>Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации.
Не надо сравнивать. Скорость машины в моем примере это не скорость компиляции и программ а скорее надежность программирования.

AVK>>То есть? Ты всерьез считаешь что я один раз определяюсь и затем пользуюсь только выбранной технологией? Это не так — технологию я выбираю для каждого проекта. В другом треде я кстати писал о совместном использовании java и .Net
VD>Ну, метания это тоже не здрово.
Кто говорит про метания. Возможность использовать наработаный опыт — один из факторов при выборе плаформы. Только он не определяющий.

AVK>>Я ведь и плохие моменты java тоже отмечаю.
VD>А я вот этого ни разу не заметил. :( Ткни носом, плиз.
boxing/unboxing к примеру.

AVK>>У меня тоже.
VD>Ну, тогда того... по тише налетай. А то у мегя впечатление создалось, что ты не нашол пимпочки и давай крыть всю платформу... :)
Да нет — просто хочу сказать что недостатки в дотнете есть и кое в чем он похуже java.

VD>А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа...
Тогда уж лучше было бы ввести какой нибудь специальный механизм для классов, выделить их отдельно и соответственно настроить GC на работу с ними, т.е. убрать отложеное удаление, принудительно запускаться или даже реализовывать пул.

VD>>>Не, ну, нормально. Может этот спор я начал?
AVK>>Может я?
VD>А кто же?
Не я :)

VD>На, Нэте не знаю, а на VB в свое время ушло два с половиной месяца и не на простенький, а на очень даже ядреный.
На 1С день с нуля. Полмесяца с отладкой и внедрением.

AVK>>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего.
VD>Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать.
Но таки 1С практически монополист на этом рынке.

AVK>> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.
VD>Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет.
Вот вот.

VD>Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад. :)
2 уже. Так я о том и говорю — молодой он еще.

VD> Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения.
Вот и посмотрим.

VD>>> И главное, что я не вижу как я могу реализовать свои идеи и удовлетворить свои потребности средствами этой платформы.
AVK>>Ну так рассказывай про свои потребности.
VD>Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее?
Сам понимаешь — ActiveX это уже однозначно технологии от MS. Политика у него такая. J++ напомнить? Там ведь как раз из-за COM поцапались.

VD>>> Мне ведь нужно соблюдать генеральную линию партии.
AVK>>А кому нужно?
VD>Так ты сам говорил, чтобы использовать Яву нужно придерживаться определенной стратегии...
И при использовании дотнета тоже. И генеральная линия партии тут не при чем.

VD>А то чтобы все моих сегодняшние наработки не превратились в прах. И чтобы я мог делать то, что хочу, а не то что получается.
Ну так это не недостатки или достоинства платформы а твой конкретный случай. Точно так же если у меня основные наработки под CORBA — я дотнет ни при каких условиях использовать не буду.

VD>Если у тебя прокты пеняются по разу в год, то тебе так можно. Я вот 7 лет иду к одной идее.
Не раз в год. Но меняются.
VD> И на следующие 5 работы найдется, а технологии приходтя и уходят. Если я нучну прыгать выбрасывая все наработки, то вообще ничего не сделаю. :(
У меня тоже идеи кое какие есть. Только их можно реализовать и на том и на другом и на обоих сразу.

AVK>>Если не переучиваться — кому сейчас нужен такой специалист? Так что учиться и переучиваться придется, причем всю жизнь.
VD>Да я и не спорю с этим, но переучиваться и переделывать все с нуля это две большие разнецы.
Всегда приходится начинать с нуля. На дотнет же ты перешел. Мне с java это сделать было просто, все таки технологии очень похожи. А вот тебе с С++?

VD>Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то?
Чем больше?

VD>Т.е. ты не говорил, что MSDN бяка?
Да все оно по большому счету бяка, и MSDN и javadoc. :)

Здравствуйте VladD2, Вы писали:

VD>Кстати, очередь, похоже тоже сделана на массиве. Иначе бы у нее не было бы капасити, не нужен такой параметр для связанных списков. Видимо делают змейку...
В смысле скользящий по массиву указатель начала очереди? Может быть. Тогда понятно почему IList не реализован.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Неа, не угадал

AVK>>Это GC родимый шуткует. Миллион объектов — это много и во втором цикле запускается GC, прибивая память за предыдущим. Я поправил — теперь все харашо.
VD>Ну, тогжа запусти мой вариант посмотри на результаты...
А ты мой запусти, с вызовом GC.

AVK>>Да еще и кастинг выкидываешь за счет хранения простых типов.
VD>Ну, а ты что же хочешь чтобы производительность из воздуха бралась? Тебе этот кастинг нужен?
Нужен

AVK>> Плюс отсутствуют затраты на new.
VD>Ну? Вот и подумай на фига козе баян. Зачем нюь для int? А это ведь самый распространенный тип...
Для списков самый распространенный тип — классы.

AVK>>Плюс используются типы by value и нет выделения памяти в куче и GC.
VD>Ну? Так того и добивались, а с обжектом ты плучаешь весь этот кайф, а он ведь тебе не нужен.
Он мене как раз нужен.

AVK>> Увы, чаще всего надо хранить объекты и возможный максимальный размер может быть сильно больше чем среднерабочий.

VD>Ну, при неаравильном приектировании конечно. А при правильном лучше хранить структуры или простые типы. В общем и целом, чем мешьше памяти в куче выделяется, тем лучше. GC это правило ослобляет, но не снимае. В сложных случаях GC проигрывает обычной куче.
Он всегда в скорости проигрывает обычной куче. Зато на 100% исключает утечки памяти из-за потеряных указателей. Именно для этого его и придумали.

VD>Видишь даже с совершенно не производительным хранением информации мой вариант быстрее.

За счет capacity.

VD>Но ведь основной расчет тут делался на отбрасывание нунужных полиморфностей.
Но мне то они нужны.

AVK>>Аналогично релиз. ngen эффекта не дает. AMD XP 1466 512 памяти.
VD>Странно. Похоже у меня маина более слабая, но результаты лучше. И нген эфект дает. У меня вот сервис-пака нет. Может это как влияет?
ОС может? У меня XP. Да и винамп наверное немножечко влияет, лишний раз контекст передергивает.

Здравствуйте VladD2, Вы писали:

AVK>>Так граничные условия существуют почти для всего. Но тенденция то.

VD>Да нет никакой тенденции. Хороший софт работает на грани возможного и выжимает из железа все, что моежт, а плохой всехда называли тормозным. Так его и бдут называть...
Пример хорошего и современного софта.

VD>Проще чем софт который создается для других платформ и тем более чем софт создающийся как переносимый и/или масштабируемый.
За все надо платить.

VD>>>Ну, есть же заменитель.
AVK>>Медленнее на порядок? Это уже не заменитель.
VD>Ну, тебе показал, что технологии абстракции данных в CLR и Яве тоже медленнее на порядок, но ты же из-за этого не откажешься от них?
Потому как очень много потеряю при этом. А что я потеряю от перехода на LinkedList?

AVK>>Допиши мне EJB или хотя бы JDO, а? Я тебе даже денег заплачу, не очень много

VD>Я тебе уже говорил, что есть прекрасные заменители EJB.
Ты просто не понимаешь что такое EJB.

AVK>>COM же определяе еще и реализацию. CLR вобще ни каким местом тут не прокатывает.

VD>Это почему? Компонетная модель позволяющая создавать серверы приложений, динамически загружаемые компоненты и элементы управления. Позвоялет создавать и использовть омпоненты на разных языках, т.е. это больше чем COM и больше чем CORBA.
Так я им говорю что CLR тут никаким местом.

AVK>>Далее, к COM надо добавить LDAP сервер.
VD>Это еще зачем?
А что ты в замен CORBA registry предложишь?

AVK>>Да и двоичный tlb и текстовый IDL сравнивать трудно.
VD>А зачем их сравнивать. Вон в нет эту идею еще дальше расширели. А маньяки от корбы до сих пор кричат, что видте ли это не гибко. Это биче гибкого. Просто один раз нужно разобраться. Сгенерить IDL по tlb или создать файл C# или VB.Net по сборке проще просого.
А в дотнете уже не tlb. Тама WSDL.

VD>>>И то, что для Явы все это будет геморой,
AVK>>Так ествственно, технология то ждля нее неродная и вобщем то необязательная.
VD>Ана для меня обязательная и для многих тысяч программистов.
Ну значит для тебя и многих тысяч программистов java не подходит. Но для других многих тысяч программистов не подходит дотнет а подходит java.

VD>>>Не понял.
AVK>>Объясняю. В *nix'ах dll'ек нет, там есть so.
VD>Ну, и что? А это знаю. Что мешает мне использовать на Линуксе одно, а на Виндузе другое?
Отсутствие дотнета в Линуксе

VD>Думаю, что MS обязатеьно сделает показательную портацию .Net на какой нибудь Mac OS 10.

Про Моно ты надеюсь уже слышал?
Слышал. И про Corel портирующий дотнет на фришку тоже слышал. Но глядя на Windows.Forms берут меня жуткие сомнения. Тама половину windows переностить придется.

VD>>>Так. Во-первых, зачем в Яве или Нете кешировать объекты? Это же делается автоматически.
AVK>>Ну как бы объекты персистентные.
VD>А! Замечательная технолгия... для загрузки процессора и свободной памяти. Вот только тебе пожалуй нужно не кэш, а пул создавать.
Нет, пул как раз не подходит. Нужен именно кеш. Иначе нафига мне объект, который можно использовать только в одном месте.
VD> Проще читать данные и ассоциировать их с инстансами. К тому же объекты ининтифицируются по ID, а их нужно не в связанных списках ранить, а в map-ах.
Так у меня они в хештаблице и хранятся. Очередь для другого нужна.

AVK>>Используй DOM, а документик возьми мегабайт эдак 20-30.
VD>Ну, 30 это уже не документик, а база данных и довельно не маленькая. Прайс книжного магазина (Интернетного) занимает 12 мег. Да и выдержит он в лет. 30 мег для современного компьютера это фантики, ну а делее нужно переходить на БД.
А зачем мне бешеный расход памяти, если можно SAX'ом обработать?

ТAVK>>Чем поддержка java хуже?

VD>Да тем, что книг по Яве и Нэту на русском примеро онинаковое количество, а Нэту всего месяц.
Не показатель
VD>Тем, что по нету создано сотни форумов за это время.
В России здесь самый оживленный форум. А траффик больше мы с тобой вдвоем создаем.

ТAVK>>И чем тебя не устроила ее объектная модель?
VD>Ну, ты посмотри CodeDom, Emit, дезайнеры типов, броузер свойств, да и сами свойства которые есть в EJB, но нет в самой Яве, и т.п. И покажи аналоги в Яве. А то может я просто чего не знаю?
А объектная модель то тут при чем?

VD>Не, не чувствую. Я разницу в скорости чувствую. Мне 4 байта хранить нужно. Из солидарности с апологетами плиморфизма я этого делать не намерен.
А мне в коллекциях объекты хранить надо. Мне повеситься или утопиться?

VD>В чем опасность не понятно!
Опасность в том что изменение одной функции непосредственно влияет на остальные.

Здравствуйте AndrewVK, Вы писали:

VD>>Из всего этого отсутствует один линкед-лист. стэйтфул EJB-ей не будет по принципиальным причинам.
AVK>Это что же за такие принципиальные причины?

Они развивают свою идеологию. Им важна не только красота, но и производительность. Поэтому они или встроят все это в БД, или вообще не будут ломать копья.

VD>> Ну а обычные EJB ничем не отличаются от любого объекта .Net.
AVK>Обычные это какие? Есть четыре типа бинов
AVK>1) Stateless session
AVK>2) Stateful session
AVK>3) Entity BMP
AVK>4) Entity CMP

1 и 2.

Последние как раз не проходят по идеологическим соображениям. Хотя реализовать оба варианта на Нэте можно.

AVK>Только для первых аналогом может быть WS.

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

AVK> Вторые можно на базе WS съэмулировать. А вот 3 и 4 — это уже проблема. Особенно 4.

(Прежде чем продолжить материться поясню 3 (BMP) — это Entity компоненты с ручной записью. 4 (CMP) с автоматической, контейнером EJB-ей.)

Да нет там никакой проблемы. В прочем как и смысла от 3 и 4. :) Ты сам то их используешь? Вот MS продвигает для решения подобных задачь XML-технологии (кеширование данных на сервере приложений в формате XML). Лично я считаю, что использование обычных курсорных API доступа к БД эфективнее и проще. А абстракцию можно делать и другими методами. Ты видел ДатаСэты в Нэт?

VD>>Что такое JAAS я не знаю. :(
AVK>Java Authentication and Authorization Service

Защита по руски? Ну, с этим у нета все впорядке. Кстати, это будет одной из палок которая прогонит Яву с клиентских компьютеров. Хотя ее там и так не много. :(

AVK>>>1) LinkedList
VD>>Эмулируется... ну, ты сам знаешь чем. Если что пишится за двадцать мину.
AVK>Не эмулируется а пишется целиком ручками

Ну, вроде массив тебе подходил... Да и писать там нечего. Болше пустых разговоров.

AVK>>>2) RandomAccessFile
VD>>В Нэт файлы читаются через стримы у которых есть метод Seek. Или ты имеещь в виду нечто иное?
AVK>Ну как минимум нужно еще getLength() и setLength(). Плюс стримы оптимизированы под последовательный доступ.

Не, под что они не оптимизированы. Это твои выдумки. Я просто уверен, что они сделаны или на тех же мапнутых файлах, или на обычных CreateFale, ReadeFale, ...

AVK>>>3) MemoryMappedFile
VD>>Не имеет смысла, так как в предалах лотальной машины все данны всегда передаются через мапленную память, а с точки зрения файла это всего лишь метод доступа.
AVK>Иногда очень удобный. Не критично но в некоторых случаях время экономит.

А ты пробывал просто объет по ссылке (а то и по значению) передать? В Нэт это может оказаться очень даже шустро.

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

А чего не то? У меня с этим проблем нет... Есть еще куча API которых или нет в Яве/Нэте или реализованных в них медленне и кривее чем в родных API, и что же теперь страдать из любви к искуствау?

AVK>Java Data Objects
AVK>цитата из спецификации
AVK>JDO specification provides for interface-based definitions of data stores and transactions; and selection and transformation of persistent storage data into native Java programming language objects

Ну, и чем это отличается от EJB-ей?

VD>>Стыйтфул-объекты, т.е. эмуляция ДБ на объектах Явы в нете скорее вего не появится. Из-за того, что это не производительно и кривовато.
AVK>По поводу производительности я уже говорил — это не самое главное.

Да помню... купим Крэй. :)

AVK>Да и подобное преобразование все равно делать приходится очень часто.

Мне вот ни разу не приходилось.

AVK> Все дело в уровне абстракции и количестве ручной работы. Не устраивают CMP — есть же еще и BMP. Пиши в базу ручками наздоровье.

А меня и BMP не устраивает. Я считаю что:

UPDATE xxx SET fld1 = fld1 + 123 WHERE yyyy

Проще и эфективнее чем все эти извращения.

VD>>Возможно подобные технологии будут встроены в SQL-Сервер.
AVK>Ну xml то он уже хранит. А это по сути уже почти что объекты.

Глупость какая. Объекты — это объекты, а xml — xml (язык разметки). Да и хранить его по человечески БД еще не научилиь, робкие попытки Informix-а в серьез можно не воспринмать.

VD>> В .Net есть так называемый типизированный набор данных который выполняет похожие функции. В любом случае ставка делается на отключенные наборы данных которые могут сериализоваться в XML и пердаваться на другие серверы и клиентам. По сути другое решение того же самого.
AVK>Не, не тоже самое. Совсем не то.

Кочено. Это другое решение тех же проблем (работы с данными в приложениях).

AVK>Автоматические транзакции, в т.ч. и распределенные.

Ну, это в COM+-се (а вернее MTS-е) было за долго появления их в CORBA-е и Яве. И на сегодня COM+-самая масшатабируемая система управления распределенными тарнзакциями (ссылку на источник давать? :) ). Через некоторое время появится подобная функциональность и для Чистого Нэта, пока можно перебиться COM+-ом.

AVK> Умное кеширование везде где только можно.

Вот только ума там меньше, чем куриной башке. Ты закачай в эту хрень несколько миллионов записе и посмотри на этот великий ум. :)

AVK>Entity бины. Меппинг объектов в базу, полуавтоматически и автоматически. EJB надо сравнивать с servviced components а не с дотнетовскими объектами.

servviced components — это COM+ руками Нэта. И к твоим песням это отношения не имеет. Ну, а Entity бины — изначально дохлая идея. Вэб-обжектс замечательное доказательство ее глупости.

AVK>>>Ну так это не есть его уникальная особенность. К примеру свинг куда стройнее Windows.Forms.
VD>>Это же куда? Ты бы еще сказал быстрее. :) Убогость Свинга просто раздражает. И какая бы модель у него не была, пользоваться интерфейсами сделанными на Свинге просто не удобно.
AVK>Это тебе так кажется. По незнанию. На самом деле очень удобно. И от MVC в отличие от нета не отходит.

Я вообще не знаю, как можно отходть от реализации языка. Ты наверно имеешь в виду MFC — эту устаревшую дрехлятину. Я в ней ничего стройного не вижу. Ну, идея документ-вью... и все. Главное, что на Нэте можно создавть савременный и качественный GUI, а на свинге тормозных и убогих (функционально) монстриков.

VD>>А чем тебя дата не устраивает?
AVK>Нафига мне для редактирования данных в табличке ADO.NET тащить? Это уже пушкой по воробьям получается.

Так он все равно на машине будет стоять. И к тому же это ты не разобрался. Там только датасэты тащутся, они к ADO отношения не имеют. В конце концов уже наклепано мнофество решений от независимых производтелей, для Явы такого разнообразия никогда не появится.

VD>> К тому же ты здесь вообще смотришь не верно. У мс своих гридов от родясь не было. Они все делались разными Шариданами и в лайт-версии клались в VB. Если тебе нужен грид посмотри дополнительные компоненты.
AVK>Гы.

Что гы? Грамоно действуют. Себе забирают рынок по больше, а другим дают малеьнкие нишки. :))

VD>>По стравнению с ними все что делается для Явы (да и для дельфи) просто детски лепет.
AVK>Ты JTable видел? Особенно в 1.4. Все эти дельфовые и VB-шные гриды по сравнению с ним как раз детский лепет и есть.

А ты Инфрогистиковские? Они еще и не тормозят. :))

VD>>Понятна. Но спортивная машина... это не совсе корректно. Нэт в большинстве вслучаев все же быстрее, т.е. сам компилятор оптимальнее и есть средства явной оптимизации.
AVK>Не надо сравнивать. Скорость машины в моем примере это не скорость компиляции и программ а скорее надежность программирования.

Нда... странные ассоциации... "надежность" и "спортивная машина". :-\

И ты можешь привести пример когда Ява "надежнее" CLR?

VD>>Ну, метания это тоже не здрово.
AVK>Кто говорит про метания. Возможность использовать наработаный опыт — один из факторов при выборе плаформы. Только он не определяющий.

Это зависит от размеров опыта. :)

VD>>А я вот этого ни разу не заметил. :( Ткни носом, плиз.
AVK>boxing/unboxing к примеру.

Пожалуй, это один из не многих. А что ты думаешь про value-типы? Да и про остальные отличия Нэта?

AVK>Да нет — просто хочу сказать что недостатки в дотнете есть и кое в чем он похуже java.

Да! Нет линкедлиста. :)))

VD>>А шоб можно было создавть смарт-поинтеры в стеке. Для контроля внешних ресурсов... Накладных расходов ноль, а кайфа...
AVK>Тогда уж лучше было бы ввести какой нибудь специальный механизм для классов, выделить их отдельно и соответственно настроить GC на работу с ними, т.е. убрать отложеное удаление, принудительно запускаться или даже реализовывать пул.

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

VD>>>>Не, ну, нормально. Может этот спор я начал?
AVK>>>Может я?
VD>>А кто же?
AVK>Не я :)
А-га. Сам завелся... от сырости. :)

VD>>На, Нэте не знаю, а на VB в свое время ушло два с половиной месяца и не на простенький, а на очень даже ядреный.
AVK>На 1С день с нуля. Полмесяца с отладкой и внедрением.

Лажа на твоем 1С-е хоть день... хоть год... То что у нас за те два месяца было сделано от 1С-а отличается одним небольшим достоинством... оно мозги имело и продуманную архитектуру.

AVK>>>И сколько это будет денег стоить? Для маленьких предприятий 1С в России на данный момент лучше всего.
VD>>Я бы уж лучше какой-нить Бэст выбрал. Ну, мозгов в этом 1С нуту. Про производительность лучше вообще молчать.
AVK>Но таки 1С практически монополист на этом рынке.

Канчай ерунду говрить. У них и 20% рынка нет. Кое что отхватили в мелких торговых фирмах... На этом рынке ~60 постоянно действующих мошьных контор и еще 540 по мельче. И всем хлеба хватает.

AVK>>> Платишь сотню баксов и получаешь весьма приличный складской и бухгалтерский учет + бесплатные обновления в соответствии с весьма продуктивной деятельностью наших законодателей и чиновников.
VD>>Я тебе штук десять продуктов за туже цену могу подобрат. Разве что конструктров среди них не будет.
AVK>Вот вот.

Что вот-вот? Access и тот интелектуальнее и удобнее. Чё бы на нем "стандартные конфигурации" не наклепать?

VD>>Еще бы Яве 6 лет, а Нэт вышел тлько месяц назад. :)
AVK>2 уже. Так я о том и говорю — молодой он еще.

Да нет... Вроде официально объявили только месяц назад... Или это время летит?...

VD>> Через два гда посмотрим. Думаю, не нете будет значительно больше. К тому же Нэт можно встраивать в уже существующие приложения.
AVK>Вот и посмотрим.
Договорились.

VD>>Ну, вот есть код на С++ (пордка 350 000 строк) и на VB (~10 000). Причем исползуются технологии COM, DCOM, COM+, WSH, ActiveX... Как мне все это перевести на Яву, и что мне это даст. Если даже переписанный с нуля код будет работать медленнее?
AVK>Сам понимаешь — ActiveX это уже однозначно технологии от MS. Политика у него такая. J++ напомнить? Там ведь как раз из-за COM поцапались.

До появления Явы во всем не MS мире небыло нормальной универсальной компонентной технологии, а уж аналога контэйнера ActiveX-ов (а-ля VB) небыло и в помини. Что же нам было Яву дожидаться. Так он и сейчас не дотягиват.

VD>>Так ты сам говорил, чтобы использовать Яву нужно придерживаться определенной стратегии...
AVK>И при использовании дотнета тоже. И генеральная линия партии тут не при чем.

Я тебе уже говорил. В Нэте я волен сам вибирать как жить. Захочу буду писать на MC++ с минимальными ограничениями, вернее без них. И стаый код интегрирую.

VD>>А то чтобы все моих сегодняшние наработки не превратились в прах. И чтобы я мог делать то, что хочу, а не то что получается.
AVK>Ну так это не недостатки или достоинства платформы а твой конкретный случай. Точно так же если у меня основные наработки под CORBA — я дотнет ни при каких условиях использовать не буду.

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

VD>> И на следующие 5 работы найдется, а технологии приходтя и уходят. Если я нучну прыгать выбрасывая все наработки, то вообще ничего не сделаю. :(
AVK>У меня тоже идеи кое какие есть. Только их можно реализовать и на том и на другом и на обоих сразу.

Везет тебе. А вот я так шустро не умею. Мне приемственность нужна.

AVK>Всегда приходится начинать с нуля. На дотнет же ты перешел.

Пока не совсем.

AVK>Мне с java это сделать было просто, все таки технологии очень похожи. А вот тебе с С++?

А мне не с С++, а с COM-а. Но если бы у меня бли такие наработки на Яве, то тоже было бы сложно.

VD>>Ну, и все не состыкока? .Net — это действительно больше чем Ява, а его переносимость отымет козырную карту критиков. Что не так то?
AVK>Чем больше?

Тем, что Явная VM — это только интерпритатор байт-кода, а у нет это полнофункциональый слой, который прекрасно работает без Шарпа. Есть даже свой формат языка. MSIL — это ассемблер нового поколения. Вот CLR + C# это действительно аналог Явы. Несколько улучшенный, но аналог.

VD>>Т.е. ты не говорил, что MSDN бяка?
AVK>Да все оно по большому счету бяка, и MSDN и javadoc. :)
Хытрущый... :)

От:	VladD2	www.nemerle.org
Дата:	31.03.02 18:55
Оценка:

От:	VladD2	www.nemerle.org
Дата:	31.03.02 19:04
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	31.03.02 19:11
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	31.03.02 19:43
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	31.03.02 19:50
Оценка: