Здравствуйте, Sinclair, Вы писали:
S>Я надеюсь, уточнение сортировки в Case-insensitive/accent-sensitive для турецкой локали не усложнит эту безусловно прекрасную программу?
безусловно усложнит, как минимум придётся написать волшебный предикат, как максимум заменить std::string на что-нибудь из комплекта ICU.

Здравствуйте, hattab, Вы писали:
H>Base64 -- единственный способ передать бинарные данные в XML-RPC.
Несомненно, именно это было ключевым фактором при принятии решения о способе маршаллинга картинок в неуправляемый фильтр. Извини, не могу больше писать — встаю для аплодисментов.

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

G>Ну давайте чтобы не быть голословным приведу код:
G>....поскипано...
G>Собиралось 2008 студией, релиз, запуск из проводника.
G>C++ — 562 мсек, C# — 92 мсек.

G>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
G>#include <windows.h>

маленькая поправка

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD ticks = GetTickCount();

    for(int i=0; i<1000000; i++)
    {        
        int arr[64]; // вот ето действительно стандартный "аллокатор" на С++
    }

    printf("%d", GetTickCount() - ticks);
    getchar();
    return 0;
}

время показывать?

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

H>>Base64 -- единственный способ передать бинарные данные в XML-RPC.
S>Несомненно, именно это было ключевым фактором при принятии решения о способе маршаллинга картинок в неуправляемый фильтр. Извини, не могу больше писать — встаю для аплодисментов.

Сказать-то чего хотел?

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

H> в Delphi без блокировок 24
У нас с тобой процы разные, так что наши попугаи сравнивать без знания скока попугаев у тебя в C# проге сложновато.

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

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

G>>Ну давайте чтобы не быть голословным приведу код:
G>>....поскипано...
G>>Собиралось 2008 студией, релиз, запуск из проводника.
G>>C++ — 562 мсек, C# — 92 мсек.

G>>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
G>>#include <windows.h>

Х>маленькая поправка

Х>

Х>int _tmain(int argc, _TCHAR* argv[])
Х>{
Х>    DWORD ticks = GetTickCount();

Х>    for(int i=0; i<1000000; i++)
Х>    {        
Х>        int arr[64]; // вот ето действительно стандартный "аллокатор" на С++
Х>    }

Х>    printf("%d", GetTickCount() - ticks);
Х>    getchar();
Х>    return 0;
Х>}
Х>

Невопрос

static unsafe void Main(string[] args)
{
    var sw = new System.Diagnostics.Stopwatch();
    sw.Start();

    for (int i = 0; i < 1000000; i++)
    {
        int* ptr = stackalloc int[100];
    }

    Console.WriteLine(sw.ElapsedMilliseconds);
    Console.ReadKey();
}

Х>время показывать?
Для начала надо научиться отличать хер от пальца.

Здравствуйте, gandjustas, Вы писали:
H>>Ты же вроде отметился в ветке, где приводили пример работы MSSQL с базой на диске и в памяти... Основные задержки, это, как раз таки, выборка данных с диска.
G>Но оптимизировать эти издержки не сильно получится, только компромисс время-память.
То-то и оно.
Компромисса CPU/диск там и в помине нету — можно потратить пару миллиардов тактов только на то, чтобы понять, что некую страничку не нужно поднимать с диска.
А вот с памятью всё достаточно безрадостно — почитай того же Гарсиа-Молина на предмет того, как зависят асимптотики реляционных алгоритмов от того, какую часть промежуточных результатов можно себе позволить держать в RAMe. Поэтому удвоение memory footprint при прочих равных — это вовсе не $40 за еще одну планку памяти, а тупо просад на порядок времени выполнения некоторого запроса.

Дисклаймер: это вовсе не означает, что управляемых РСУБД не может быть. Есть масса способов свести расходы от недетерминистической финализации к минимуму; а кроме всего прочего, управляемые среды предлагают возможность не просто "компилировать планы запросов", а "по-настоящему компилировать планы запросов в натив". Что в некоторых случаях может дать чудовищный performance boost.
Ну и, естественно, проникновение на рынок аццких отжигов типа IODrive способно сильно изменить расклад сил в RDBMS-алгоритмах, благодаря сокращению разрывов между производительностью памяти и диска.
В прошлый раз этот прорыв предсказывали поклонники 64хбит архитектуры; но парни никак не могли понять, что возможность отмапить терабайтную базу в виртуальную —
это совсем-совсем не то же самое, что и поднять терабайтную базу в память физическую.

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

G>Невопрос

static unsafe void Main(string[] args)

ого! тебе осталось сделать совсем небольшой шаг до С++, решайся!

P.S. ну и что ты со своими байтами будешь делать? а как насчёт того чтобы классы на стеке инстанцировать?

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

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

G>>Невопрос

Х>

Х>static unsafe void Main(string[] args)
Х>

Х>ого! тебе осталось сделать совсем небольшой шаг до С++, решайся!
Зачем? Для запредельного перфоманса есть С, для надежного и красивого кода есть C#, F#.
А С++ в этом уравнении места нет.

Х>P.S. ну и что ты со своими байтами будешь делать? а как насчёт того чтобы классы на стеке инстанцировать?
Если уж очень надо стеке, то воспользуюсь структурами.

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

H>Сказать-то чего хотел?
Что люди, которые для решения задачи "Получить от сервера картинку" выбирают формат BMP-over-XML/RPC, мягко говоря, не имеют права критиковать дотнет за производительность.

Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)?

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

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

Без этого прогибания пальцев типа "да у меня нативный клиент отъедает всего пять метров" примерно то же самое, что и "а вот у меня прога вообще регистр EBX не использует". В том смысле, что никому не интересно, что там твоя прога "использует" внутри. Если она работает так, как нужно заказчику, то всё в порядке. Никаких других критериев в природе нет.

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

H>> в Delphi без блокировок 24
CC>У нас с тобой процы разные, так что наши попугаи сравнивать без знания скока попугаев у тебя в C# проге сложновато.

С# 103.

Здравствуйте, gandjustas, Вы писали:
Х>>ого! тебе осталось сделать совсем небольшой шаг до С++, решайся!
G>Зачем? Для запредельного перфоманса есть С, для надежного и красивого кода есть C#, F#.
G>А С++ в этом уравнении места нет.
ну как же, C++ == запредельный перфоманс + надёжный и красивый код

Х>>P.S. ну и что ты со своими байтами будешь делать? а как насчёт того чтобы классы на стеке инстанцировать?
G>Если уж очень надо стеке, то воспользуюсь структурами.
надеюсь ты понимаешь разницу между структурой и классом в дотнете, повторяюсь — инстанцировать классы

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

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



H> New(Arr);
H> Dispose(Arr);

H>Pentium M 1.7GHz. Память PC2700. Время: 67ms.

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

Впрочем, это ж Делфи.

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

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

Критично ли это для конечного пользователя — только в очень редких случаях (мне с такими не доводилось сталкиваться).
Обоснован ли такой оверхед — в большинстве случаев определенно да.

В целом управление памятью в дотнет реализовано очень-очень эффективно — так, что в исключительном большинстве случаев память не является "бутылышным горлышком".

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

H>>Сказать-то чего хотел?
S>Что люди, которые для решения задачи "Получить от сервера картинку" выбирают формат BMP-over-XML/RPC, мягко говоря, не имеют права критиковать дотнет за производительность.

Давай посмотрим на это дело детальнее. Отфонарный скриншот моего десктопа ужатый до 320x200x24, в формате BMP занимает 192,054 байт. Респонзовый пакет XML-RPC с этой картинкой занимает 256,207 байт. Картинка после gzip'а весит 54,710 байт. Пакет XML-RPC после gzip'а весит 56,093. Время обработки gzip'ом раличается в пределах погрешности замеров. Теперь прикинем, из-за разницы аж в килобайт(!) я должен заставлять разработчика клиентского приложения опускаться с уровня прикладного API (в виде XML-RPC, работая с которым, он о транспорте вообще не думает) на уровень HTTP транспорта (с погружением в RFC, заголовки и пр.), дабы дать ему альтернативный способ доступа к ресурсу

S>

Есть .Net софтинка: одна форма с кнопкой и картинкой (PictureBox). При нажатии на кнопку происходит вызов XML-RPC сервера и получение от него картинки 320x200x24 в формате BMP. После запуска клиент занимает 11.1Mb памяти. С каждым нажатием на кнопку потребление памяти растет. Постепенно вырастает до 21.2Mb, и на этой цифре останавливается (ну с мелкими мотыляниями туда-сюда). В аналогичном нативном клиенте потребление не превышает 5Mb. В цем тут вина .Net разработчика (там кода -- одна строка)?

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

Давай ты не будешь вытаскивать фразы из контекста и манипулировать ими по своему усмотрению

S>Ну, а в целом по больнице, нужно не смотреть всякую фигню в таскменеджере, а ставить перед собой задачи и смотреть, как они решаются. В частности, к примеру, профилировать, сколько времени занимает "забрать картинку с сервера" в нативном и управляемом клиенте и укладывается ли это в заданные параметры.
S>В частности, брать тестовую среду, близкую к реальной, и смотреть, по прежнему ли всё укладывается.
S>Не имеет смысла сравнивать распределенную память у двух программ, когда еще полтора гига свободно. Нужно запускать, к примеру, обе программы на 512 метрах памяти, с открытым в параллель офисом или чем еще там требуется по задаче, и мерить, мерить, мерить, мерить.

Синклер, я уже писал, что у меня не стояло задачи сравнить XML-RPC.NET со своей нативной реализацией.

S>Без этого прогибания пальцев типа "да у меня нативный клиент отъедает всего пять метров" примерно то же самое, что и "а вот у меня прога вообще регистр EBX не использует". В том смысле, что никому не интересно, что там твоя прога "использует" внутри. Если она работает так, как нужно заказчику, то всё в порядке. Никаких других критериев в природе нет.

Неверные выводы на основе неверно исталкованых слов...

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

C>Вообще все эти сравнения и пиписькомеренья весьма забавно выглядят.
Забавно, да.
Ну это ты предъявы к зачинщику

Автор: gandjustas
Дата: 19.03.09

предъявляй.

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

Х>Здравствуйте, gandjustas, Вы писали:
Х>>>ого! тебе осталось сделать совсем небольшой шаг до С++, решайся!
G>>Зачем? Для запредельного перфоманса есть С, для надежного и красивого кода есть C#, F#.
G>>А С++ в этом уравнении места нет.
Х>ну как же, C++ == запредельный перфоманс + надёжный и красивый код
И то и другое неправда.


Х>>>P.S. ну и что ты со своими байтами будешь делать? а как насчёт того чтобы классы на стеке инстанцировать?
G>>Если уж очень надо стеке, то воспользуюсь структурами.
Х>надеюсь ты понимаешь разницу между структурой и классом в дотнете, повторяюсь — инстанцировать классы
Я то как раз отлично понимаю, а вы — видимо нет.

Х>и на посошок, или я проглядел, или ты не ответил на вопрос — сколько у тебя установлено приложений уровня "десктоп", писаных на дотнете?
Сколько установлено — не считал, пользуюсь двумя — paint.NET и Windows Live Writer. Это треть софта, который я ставил и пользуюсь им.

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

H>> New(Arr);
H>> Dispose(Arr);

H>>Pentium M 1.7GHz. Память PC2700. Время: 67ms.

C>Если компилятор не дурак, то он вообще не станет выделять память по пусту, раз Вы ее не используете и пустой цикл тоже не станет крутить по чем зря.

C>Впрочем, это ж Делфи.

Вай-вай, говнодельфи укопал мегашарпа... Смотри не лопни, от злости

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

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

C>Вообще все эти сравнения и пиписькомеренья весьма забавно выглядят. В управляемом коде в целях безопасности, афаик, при выделении памяти производится так же ее очистка (обнуление), а это по два такта процессора на каждый байт.
Кроме того я в тесте кроме выделения памяти померил еще и время двух миллионов проверок на попадание в границы массива и присваивания.
примерно 5% времени занимает.

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

H>Base64 -- единственный способ передать бинарные данные в XML-RPC.

Так Вы сами себе злобные буратины, раз выбрали такой стандарт. Что мешает бинарные передавать обычным http stream`ом?

C>>Java-like нотация записи методов (getScreenshot64) — моветон.

H>Это негласный стандарт в XML-RPC.

Ой да ну? А можно ссылку на этот "негласный стандарт". Очень хочу посмотреть.

C>>В С# нет оператора :=

H>Писал по памяти. Pascal мой основной язык.

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

C>>Неиспользование using для MemoryStream — утечка ресурсов.

H>Чего-то я не понял, а каким ресурсом, кроме собственно памяти, владеет MemoryStream?
1) для любого класса, реализующего IDisposable следует вызывать Close/Dispose
2) любой Stream по окончании работы с ним следует закрывать (помечая его тем самым closed)

C>>Читабельность Picture.Bitmap.LoadFromStream(TXmlRpcBase64(XmlRpcServerProxy('http://127.0.0.1/').keyhole.getScreenshot64(320, 200)).AsStream); -- отвратительная.

H>Еще раз: это тестовый пример.
Что-то мне подсказывает, что Ваш код выглядит не лучше этих "тестовых примеров".