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

PE>>Вот интересно, зачем же тогда половина стринга написана на нативном С++?

VD>Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.

А где это можно посмотреть ?

VD>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.

Копирование строки — нативная функция.

VD>Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.

Это точно. А ассемлерные программы всегда тормозные в принципе.

VD>Где? Вот у нас на сервере мс-сиквел и АСП.НЭТ. Так сиквелу памяти нехватает, а АСП вроде не кашляет.

А что, окромя сиквела и АСП нет других применений ?

PE>>Он слишком долго отслеживает ссылки, если их слишком много.

VD>Слишком много это сколько? Миллион отслеживает почти молниеносно. Да и делается это не постоянно.

Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.

PE>>Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.

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

Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф.
Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.

PE>> Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.

VD>Это давно решенные задачи. Если конечно велосипед не изобретать. Ну, и главно ошеломляюще быстрее на С++ их один фиг не решить. Ну попробуй хоятбы не медленнее и без нативных фичек.

Давно — это конечно. Осоенно если учесть, что это самая актуальная тема для диссеров.

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

PE>>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.

VD>Пустой треп.

Конечно. Не буду же я тебе мегабайты кода слать.

PE>>Серилизация это вообще отдельный случай.

VD>Реализация по умолчанию не быстрая. Но в С++ ее вообще нет, так что сравнивать не с чем. А реализовать ее быстро можно и там, и там.

Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.

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

PE>>

PE>>            for(int j=0; j<100000; ++j) 
PE>>            {
PE>>                OnEvent += new EventHandler(OnEventOccured);
PE>>            }
PE>>

VD>А зачем может понадобиться добавлять обработчик события 100000 в одино место?

Загляни а серилизацию. Там аккурит такой случай.

http://www.rsdn.ru/Forum/Message.aspx?mid=546331&only=1

Автор: Plutonia Experiment
Дата: 20.02.04

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

PE>>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.

VD>А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.

Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.

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

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

PE>>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.

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

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

PE>>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.

VD>И в чем разница?

Разница в том, что в сетях среднее количество референсов на один оъект около 30. Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.

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

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

PE>Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.

Я как честный линуксоид отвергаю все инсинуации.

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

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

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

PE>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.

Согласен, неудобно. Но скрость то тут причем? А над удобством мы уже рабьотаем: http://rsdn.ru/?article/rsharp/rsharp.xml

Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004

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

VD>>Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.

PE>А где это можно посмотреть ?

Здесь http://rsdn.ru/mag/0603/Collections.XML

VD>>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.

PE>Копирование строки — нативная функция.

Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.

VD>>Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.

PE>Это точно. А ассемлерные программы всегда тормозные в принципе.

Не стоит передергивать. Если бы ты сам попытался разобраться, то поразился бы этим фактом.

PE>А что, окромя сиквела и АСП нет других применений ?

Есть еще ннтп и почта. ННТП криво написан, а почта почти ничего не жрет. Так что за ресурсы дерется дотнет и сиквел. Но причем тут это?

PE>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.

8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.

PE>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф.
PE>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.

И есть эквивалентные реализации для дотнета и С++?

PE>Давно — это конечно. Осоенно если учесть, что это самая актуальная тема для диссеров.

Для дисеров? Ну, это не ко мне. А приличный звук и видео у меня уже лет 5.

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

PE>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.

А профайлер по этому поводу что говорит?

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

PE>И у меня быстрее будут делегаты работать ?

Нет. Только ифы и свитчи.

PE> Придется без них изобретать дополнительный геморрой.

Интерфейсы?

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

Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.

PE>Разница в том, что в сетях среднее количество референсов на один оъект около 30.

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

PE>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.

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

PE>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.

Оптических? Вряд ли. Но не думаю что граф от этого станет другим.

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

PE>Загляни а серилизацию. Там аккурит такой случай.

PE>http://www.rsdn.ru/Forum/Message.aspx?mid=546331&only=1

Автор: Plutonia Experiment
Дата: 20.02.04

Если бы вы меня спросли как с эитм быть, я бы ответил — делайте собственный фрэймворк сериализации и не возитесь с этим. Или ждите видби и оркас. Там обещали разогнать сериализацию.

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

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

VD>Я как честный линуксоид отвергаю все инсинуации.

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

VD>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...

Можно попробовать хотя бы преобразование фурье набомбить.

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

PE>>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.

VD>Согласен, неудобно. Но скрость то тут причем? А над удобством мы уже рабьотаем: http://rsdn.ru/?article/rsharp/rsharp.xml

Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004

Неудбоно — с этим можно мириться, если проект небольшой.
На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.
В этом коде дублирование очень неслабое.

А что бы отказаться от дублирования пришлось подключить рефлексию. Для ускорения пришлось писать кеши для всего — аттрибуты, проперти, имена методов и тд.
А вот как ускорит создани делегатов неизвестно. Это занимает ровно половину времени десерилизации. Колбек интерфейсы влекут массу геморроя за собой. Усложнять не хотелось бы.
С десекрилизацией проще, но тогда будет с серилизацией проблемы — это увеличит кличество ссылок на объект, что повлечет усложнение суррогатов и создание излишнебольшого количества WriteObjectInfo.

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

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

VD>>Я как честный линуксоид отвергаю все инсинуации.

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

VD>>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...

PE>Можно попробовать хотя бы преобразование фурье набомбить.

Во...Хорошее предложение

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

VD>>>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.

PE>>Копирование строки — нативная функция.

VD>Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.

Угу. В файле strcat.c из CRT есть такое

/***
*char *strcpy(dst, src) - copy one string over another
*
*Purpose:
*       Copies the string src into the spot specified by
*       dest; assumes enough room.
*
*Entry:
*       char * dst - string over which "src" is to be copied
*       const char * src - string to be copied over "dst"
*
*Exit:
*       The address of "dst"
*
*Exceptions:
*******************************************************************************/

char * __cdecl strcpy(char * dst, const char * src)
{
        char * cp = dst;

        while( *cp++ = *src++ )
                ;               /* Copy src over dst */

        return( dst );
}

Такого ассемлера я не знаю.

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

Да при том, что С# и дотнет не является панацеей. Универсальность и дешевизна разработки. Но в некоторых областях производительность важнее.

PE>>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.

VD> 8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.

Так профайлер говорит.

PE>>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф.
PE>>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.

VD>И есть эквивалентные реализации для дотнета и С++?

Есть. Все писали мы. Искренне жаль, но конкурентов до прошлого года у нас не было.

Здравствуйте, Аноним, Вы писали:

А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.
А>Какие были впечатления? Не хочется ли обратно?)
А>Мне вот сейчас как раз это предстоит.

Перешёл на C# год назад, в бэкграунде остались около 4 лет программирования на С++.
Впечатления — большей частью положительные. Насчёт обратно — нет, не хочется,
больно уж быстро и безошибочно удаётся прогать , особенно n-звенные системы, GUI,
работа с БД. Единственное, что пока немного
огорчает — это отсутствие релизных CRL и компилятора, поддерживающих generics (тоскую по
шаблонам С++, и жду релиза, бетами не хочется пользоваться , хотя и понимаю, что
извратов на шаблонах, которыми баловался на С++, уже не сотворить — оно может и к лучшему ). Ещё не хватает STL, причём — честно говоря, иногда даже очень сильно
А насчёт множественного наследования — так оно мне за 6 лет прогания только 2 раза
пригодилось , так что в принципе — и без него жить можно .
Хотя иногда( а это происходит всё реже и реже, надо сказать ), тёмными вечерами — прогаю на чистом ISO/IEC 14882 С++. Ностальгирую, так сказать .
P.S.

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

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

K>>Когда задача очень большая, то и хип нам не друг.
VD>И есть документальное подтверждение на которое можно дать ссылку?
Пжста: http://qform3d.com/index.php?lang=ru
Вся работа с памятью сделана ручками, ибо не хватает ее родимой. Все 1.5 гига которые можно реально урвать на процесс расписаны и поделены. Плюс решатель в отдельном процессе 800МБ кушает.

K>> В таких случаях делается пул и хип и ГЦ остаются далеко позади.
VD>Да качественный ЖЦ и есть по сути пул.
Пул он при любых условиях пул. А ГЦ с какогото момента уже не пул, а проклятье.

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

static mem_mgr<CNode,QMemTraits>    CNode_mm;

void* CNode::operator new( size_t sz ) {
    return CNode_mm.alloc();
}

void CNode::operator delete( void *p ) {
    CNode_mm.free( p );
}

дальше продолжать?

VD>Удаляется... если памяти нехватает и если на объект нет ссылок. А если хватает, то ради чего его удалять? Чтобы процессор занять?
А если не хватает?

VD>Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул.
Это наверное, шутка?

K>> Наверное на С++ переписывать будем

VD>Ни разу пока не нужно было. Но если я пийду к выводу, что на С++ я смогу ускорить ту или иную часть приложения и это действительно нужно, то я сделаю это не задумываясь. А почему бы и нет? Но ради скорости одного-двух фрагментов кода тратить столько сил и времени... зачем?
А если эти фрагменты 80% кода. Можно конечно остальные 20 (ГУЙ и прочее) на НЕТ перевести, но какой смысл? Я не вижу.

K>>Представь что программа на каждой итерации создает и освобождает ~200К обьектов.
VD>Это очень выгодный для ЖЦ сценарий. Дон Бокс даже демонстрировал приемущества ЖЦ над хипом С++ создавайя в цикле объект и уничтожая его.

То что показал бокс — это какая-то пародия на тест. Могу написать реальный на котором ГЦ заткнется. А С++ будет летать.

VD>В ЖЦ есть специальные оптимизации на такой случай. Все эти объекты попадут в первое поколение и будут очень эффективно освобождены. Причем тогда когда процессор будет свободен, ане во время алгоритма.
Это когда же он будет свободен если алгоритм несколько дней работает?

VD>Да и все разговоры о пуле — это теория. На практике осннвные массы таких фич не используют. И выходит не быстрее чем с ЖЦ.
Для кого-то теория, а для меня обычная повседневность жизни. А фичи эти не используют пока все устраивает. А как только появляется узкое место, то прикрутить пул пустяковое дело. Тогда все начинает летать. Что и видно невооруженным глазом.

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

А если нет особой разницы то зачем куда-то переходить? Только ради ГУЯ? А во всем остальном иметь мучения.

З.Ы. Кстати еще про пул. (Исходник здесь: http://rsdn.ru/File/16157/mem_mgr.h)
Операция выделения:

    block* alloc_() {
        block *p = cur_->free;
        if ( p ) { // идеальный случай
            cur_->free = p->next;
            cur_->used_n++;
            return p;
        }
// неидеальный происходит один раз в несколько тысяч раз (в зависимости от размеров и настроек)
        chunk *c = first_;
        for ( ; c; c = c->next ) {
            p = c->free;
            if ( p ) {
                cur_ = c;
                cur_->free = p->next;
                cur_->used_n++;
                return p;
            }
        }

        c = chunk_alloc_();
        if ( c ) {
            p = c->free;
            cur_ = c;
            cur_->free = p->next;
            cur_->used_n++;
            return p;
        }

        return (block*)Tr::out_of_mem();
    }

удаление:

    void free_( void *p ) {
        block *pb = (block*)p;
        chunk *c = (chunk*)((size_t)p & (size_t)chunk_mask_);
        pb->next = c->free;
        c->free = pb;
        c->used_n--;
    }

Ну и какой ГЦ сможет с этим потягатся?

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

PE>> Придется без них изобретать дополнительный геморрой.

VD>Интерфейсы?

И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном.
Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много.
Классов очень много. Интерфейсов еще больше. Вот такие дела.

VD>Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.

Быстрее, но для графа он неприменим.

PE>>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.
VD>Ну, так ты сам знаешь чего не надо делать. Остается только сделать как надо используя быстрые подходы.

Тогда это копипейст и размножение классов.

PE>>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.

VD>Оптических? Вряд ли. Но не думаю что граф от этого станет другим.

Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.

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

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

PE>>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.

VD>А профайлер по этому поводу что говорит?

Routine Name    Time    Time with Children    Shared Time    Hit Count
DatasetStorageEngine::Load    0.00665421125    18.7413820525    0.0355054458169608    36
ProductLibraryManager::LoadProdLibWorker    0    17.78354583875    0    1
ProductLibDataSetPersist::DsLoad    0.00084167625    16.797909685    0.00501060111515893    1
DataSetLoader::Load    0.00016143625    16.3967278325    0.000984563820593623    1
TabInfo::Load    1.44434606875    16.38647400125    8.81425783630952    77
<Garbage Collector>    11.63491199375    11.63491199375    100    308
<JIT Compiler>    11.48328216    11.485244375    99.9829153395789    13864
ZipStorageEngine::Load    3.43084997875    8.962737435    38.2790414606182    5
PersistManager::Load    6.76625E-6    8.9577977525    7.55347484610448E-5    4
PropInfo::Load    1.00993600125    8.8353232525    11.430662720396    59387
DocumentManager::GetNetworkObject    3.855E-6    8.7928121725    4.38426287787282E-5    2
ValidatableEventSource::SetValidatableProperty    0.32878773    7.88257587    4.1710696531488    43581
EventSourceObject::GetPropertyDescriptionInternal    0.10383751375    7.5208579025    1.3806604924085    87539
EventSourceObject::BuildPropertyDescriptionMap    6.34245147625    7.469254285    84.9141190572012    15229
EventSourceObject::GetPropertyDescriptionMapInternal    0.0282405075    7.4341745525    0.379874151468547    88041
IndexableNamedObject::set_Name    0.1251015475    7.386138655    1.69373407870313    12125
EventSourceObject::GetPropertyDescription    0.0155469175    6.36041299    0.244432516008681    62998
AppController::RunWizard    0.00045296125    6.18196760125    0.00732713723553664    1
ScriptManager::ExecuteFile    0.00122776    6.17574920875    0.0198803409675456    1
ScriptManager::ExecuteString    3.77125E-5    6.16964905875    0.00061125843043722    1
SAXEngine::VPI.NC.Scripting.IScriptEngine.Execute    1.365692915    6.1415065075    22.2370995346535    1
DocumentManager::SaveDocument    6.206E-5    5.70805727375    0.00108723506131235    1
DocumentManager::Save    0.00057522625    5.69897192    0.0100935091113767    1
ZipStorageEngine::Store    2.32114413375    4.8816617725    47.548237504404    6
PersistManager::Store    3.919625E-5    4.881230335    0.00080299939379935    4
DocumentManager::OpenDocument    0.05199691375    3.13453559625    1.65883947249495    1
DocumentManager::OpenDoc    0.00052821    2.9891938675    0.017670650463423    1
BaseCollection::.ctor    0.000103765    2.0311321375    0.00510872720116172    7892
ReadOnlyBaseCollection::.ctor    0.011396135    2.027203835    0.56216029208528    7892

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

PE>>http://www.rsdn.ru/Forum/Message.aspx?mid=546331&only=1

Автор: Plutonia Experiment
Дата: 20.02.04

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

Это в планах, но на это нужно много времени.

VD>Кстит, если хочешь сделай тест демонстрирующий тормоза, а я прогоню его на видби.

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