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

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

G>>Ну покажите примеры программ на десктопе которые тормозят и жрут память?

H>О-о-о! Их есть у меня Это чудо называется Creative Docs .NET. После запуска, без открытого документа, мило кушает 192 метра + виртуалки в районе 180 (по показаниям ProcessExplorer'a). Скорость работы с документом тоже потрясная: при скроллинге сперва прокручиваются линейки, а потом, неспешно, за ними ползет содержимое документа. Терпения хватает только на посмотреть. PM 1.7 512Mb NVidia GeForceFX Go5200.

Ну напишите получше на C+ или на вашем любимом Delphi.
Или просто не пользуйтесь тормознутым барахлом.

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

G>>>Продажи к свойствамя языка никакого отношения не имеют.
NBN>>Имеют достаточно прямые. На яве и шарпе нельзя написать качественный продукт удовлетворяющий требованиям
G>Черт, а я писал, наверное не так что-то делал.

Ты всё время забываешь про такую штуку как требования

Здравствуйте, gandjustas, Вы писали:
G>>>Если не верите, то попробуйте написать алгоритм решения задачи: "вывести на экран все строки текстового файла, в которых более трех слов, отсортированные по алфавиту".
G>Можете запостить сюда код решения на C++

ifstream inputStream(filePath);
string currentString;
const regex expression("(\\w+)\\s(\\w+)\\s(\\w+)");
multiset<string> matched;
while(getline(inputStream, currentString))
{
  if (regex_search(currentString, expression))
    matched.insert(currentString);
}
copy(matched.begin(), matched.end(), ostream_iterator<string>(cout, "\n"));

немного непонятно что ты в етой задаче нашёл такого "сложноописуемого" на с++

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

G>>>>Вот так и с дворником — пока мусор никому не мешает, он его убирать не будет, перед тем как кому-то он сможет помешать — сразу же уберет.

H>>Я вчера решил помониторить сборку xmlrpc для .Net (http://www.xml-rpc.net/). В общем, на каждый вызов метода через XML-RPC (метод принимает два параметра и возвращает бинарник на ~200Kb) происходит 3 вызова сборщика мусора (мониторил ProcessExplorer'ом). Я на перформанс даже тестировать не стал...

G>Сборка мусора иногда происходит и что?

3 раза на один вызов это иногда? Несколько последовательных вызовов сразу задирают тактовую частоту с 600 до 1700, при том, что при аналогичных действиях из нативного клиента частота поднимается максимум до 800. Тут нужно пояснить, что вся тяжелая работа (линейный скаллинг картинки) делается в нативном сервере (он запущен локально), клиентская часть лишь формирует запрос и получает ответ т.е. ее работа минимальна.

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

G>>>Ну покажите примеры программ на десктопе которые тормозят и жрут память?

H>>О-о-о! Их есть у меня Это чудо называется Creative Docs .NET. После запуска, без открытого документа, мило кушает 192 метра + виртуалки в районе 180 (по показаниям ProcessExplorer'a). Скорость работы с документом тоже потрясная: при скроллинге сперва прокручиваются линейки, а потом, неспешно, за ними ползет содержимое документа. Терпения хватает только на посмотреть. PM 1.7 512Mb NVidia GeForceFX Go5200.

G>Ну напишите получше на C+ или на вашем любимом Delphi.

Не нужно обижаться, ты сам примеры просил...

G>Или просто не пользуйтесь тормознутым барахлом.

Я и не пользуюсь

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

H>О-о-о! Их есть у меня Это чудо называется Creative Docs .NET. После запуска, без открытого документа, мило кушает 192 метра + виртуалки в районе 180 (по показаниям ProcessExplorer'a). Скорость работы с документом тоже потрясная: при скроллинге сперва прокручиваются линейки, а потом, неспешно, за ними ползет содержимое документа. Терпения хватает только на посмотреть. PM 1.7 512Mb NVidia GeForceFX Go5200.
Creative Docs .Net словно на бете WPF делали — жуткие шрифты какие-то
И всё же там не 192 и даже с открытым документом:

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

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

G>>>>>Вот так и с дворником — пока мусор никому не мешает, он его убирать не будет, перед тем как кому-то он сможет помешать — сразу же уберет.

H>>>Я вчера решил помониторить сборку xmlrpc для .Net (http://www.xml-rpc.net/). В общем, на каждый вызов метода через XML-RPC (метод принимает два параметра и возвращает бинарник на ~200Kb) происходит 3 вызова сборщика мусора (мониторил ProcessExplorer'ом). Я на перформанс даже тестировать не стал...

G>>Сборка мусора иногда происходит и что?

H>3 раза на один вызов это иногда? Несколько последовательных вызовов сразу задирают тактовую частоту с 600 до 1700, при том, что при аналогичных действиях из нативного клиента частота поднимается максимум до 800. Тут нужно пояснить, что вся тяжелая работа (линейный скаллинг картинки) делается в нативном сервере (он запущен локально), клиентская часть лишь формирует запрос и получает ответ т.е. ее работа минимальна.
Ну так вы померяйте перформанс, а то какие-то пространные размышления ни о чем.

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

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

G>>>>Продажи к свойствамя языка никакого отношения не имеют.
NBN>>>Имеют достаточно прямые. На яве и шарпе нельзя написать качественный продукт удовлетворяющий требованиям
G>>Черт, а я писал, наверное не так что-то делал.

NBN>Ты всё время забываешь про такую штуку как требования
Я про требования ни разу не забывал.

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

H>3 раза на один вызов это иногда? Несколько последовательных вызовов сразу задирают тактовую частоту с 600 до 1700, при том, что при аналогичных действиях из нативного клиента частота поднимается максимум до 800. Тут нужно пояснить, что вся тяжелая работа (линейный скаллинг картинки) делается в нативном сервере (он запущен локально), клиентская часть лишь формирует запрос и получает ответ т.е. ее работа минимальна.
Ну мало ли что там делает это один вызов. Ты не на число запусков сборщика смотри, а на общий перформанс. При этом я ничего не обещаю, просто хочу сказать, что не стоит так сильно заморачиваться почему происходит вызов GC. В конце концов тот же rpc-xml может это сам явно делать по каким-то своим умозаключениям. У меня вот в WPF'ной проге, окна иной раз не собираются по 10-20 минут. Можно ли быть уверенным, что моя прога в сто раз быстрее твоей?

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

H>>О-о-о! Их есть у меня Это чудо называется Creative Docs .NET. После запуска, без открытого документа, мило кушает 192 метра + виртуалки в районе 180 (по показаниям ProcessExplorer'a). Скорость работы с документом тоже потрясная: при скроллинге сперва прокручиваются линейки, а потом, неспешно, за ними ползет содержимое документа. Терпения хватает только на посмотреть. PM 1.7 512Mb NVidia GeForceFX Go5200.
MK>Creative Docs .Net словно на бете WPF делали — жуткие шрифты какие-то

Да, глаза он мне все поломал Там на сайте написано, что у них какая-то своя библа, вроде даже с AntiGrain.

MK>И всё же там не 192 и даже с открытым документом:
MK>

У меня отложилось 192, я пробовал, когда его упомянули в теме о продуктах МС.

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

H>У меня отложилось 192, я пробовал, когда его упомянули в теме о продуктах МС.
Я, кстати, обратил внимание, что подобное было при первом запуске. Отодрал не 192, около 112 болтался.
Но все последующие запуски держались в районе 70-80 после всяких прокруток и зумов сэмпловых документов.

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

H>>>>Я вчера решил помониторить сборку xmlrpc для .Net (http://www.xml-rpc.net/). В общем, на каждый вызов метода через XML-RPC (метод принимает два параметра и возвращает бинарник на ~200Kb) происходит 3 вызова сборщика мусора (мониторил ProcessExplorer'ом). Я на перформанс даже тестировать не стал...

G>>>Сборка мусора иногда происходит и что?

H>>3 раза на один вызов это иногда? Несколько последовательных вызовов сразу задирают тактовую частоту с 600 до 1700, при том, что при аналогичных действиях из нативного клиента частота поднимается максимум до 800. Тут нужно пояснить, что вся тяжелая работа (линейный скаллинг картинки) делается в нативном сервере (он запущен локально), клиентская часть лишь формирует запрос и получает ответ т.е. ее работа минимальна.
G>Ну так вы померяйте перформанс, а то какие-то пространные размышления ни о чем.

Чтоб полноценно померить перформанс нужно и сервер под .Net писать, а мне пока есть чем заняться Я же, просто посмотрел на работу клиентской части.

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

G>Почему это? На C++ в среднем надо написать больше кода для получения того же функционала, значит больше трудозатраты, значит увеличивается делитель в формуле, а следовательно уменьшается качество.

Странные мотивы движут вами писать подобный бред.

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

G>Такая ситуация существует и на практике. Множественные операции выделения-освобождения памяти происходят гораздо бытсрее в коде на .NET, чем в коде на C++.

Большая часть "выделения-освобождения памяти" на С++ не затрачивает никаких ресурсов, как может быть быстрее ?

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

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

G>>Такая ситуация существует и на практике. Множественные операции выделения-освобождения памяти происходят гораздо бытсрее в коде на .NET, чем в коде на C++.

M>Большая часть "выделения-освобождения памяти" на С++ не затрачивает никаких ресурсов, как может быть быстрее ?

Да ну?
Вым наверное стоит изучить как аллокаторы и GC работают.

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

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

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

G>>>Такая ситуация существует и на практике. Множественные операции выделения-освобождения памяти происходят гораздо бытсрее в коде на .NET, чем в коде на C++.

M>>Большая часть "выделения-освобождения памяти" на С++ не затрачивает никаких ресурсов, как может быть быстрее ?
G>
G>Да ну?
G>Вым наверное стоит изучить как аллокаторы и GC работают.

Вы такими фразами или шутите или демонстрируете свое невежество.

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

D>>Кто сказал, что GC ГАРАНТИРУЕТ выделение памяти не более чем три раза больше чем в данный момент используется системой?
G>Этого не гарантирует даже аллокатор ОС, в принципе этого не может гарантировать никто.

Рекомендую ознакомиться с алгоритмами алокаторов более подробно .

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

H>>3 раза на один вызов это иногда? Несколько последовательных вызовов сразу задирают тактовую частоту с 600 до 1700, при том, что при аналогичных действиях из нативного клиента частота поднимается максимум до 800. Тут нужно пояснить, что вся тяжелая работа (линейный скаллинг картинки) делается в нативном сервере (он запущен локально), клиентская часть лишь формирует запрос и получает ответ т.е. ее работа минимальна.

MK>Ну мало ли что там делает это один вызов.

Работа конкретно xmlrpc.net в данном случае это: сериализация двух параметров + имя метода в формат пакета XML-RPC, передача на сервер по HTTP/1.1, получение ответа и его десериализация в объектную модель.

MK>Ты не на число запусков сборщика смотри, а на общий перформанс. При этом я ничего не обещаю, просто хочу сказать, что не стоит так сильно заморачиваться почему происходит вызов GC.

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

MK>В конце концов тот же rpc-xml может это сам явно делать по каким-то своим умозаключениям. У меня вот в WPF'ной проге, окна иной раз не собираются по 10-20 минут. Можно ли быть уверенным, что моя прога в сто раз быстрее твоей?

В коде xmlrpc.net явного вызова GC.Collect нет.

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

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

COF>>Вообще, я же не против .нет, я против огульного охаивания C++ определенными дот-нетчиками
MK>Вот тут я тебя полностью понимаю. И я тоже против огульного охаивания .Net и его приравнивания к VB.

Ну раз такая пьянка пошла, я тогда против огульного охаивания VB и приравнивания его к... ну пусть к Дельфям

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

A>Ну раз такая пьянка пошла, я тогда против огульного охаивания VB и приравнивания его к... ну пусть к Дельфям
Я тоже. Делфи круче. Ваше здоровье !