Здравствуйте, Sheridan, Вы писали:
>> Зависит от теста. По моим личным наблюдениям, в среднем так. Иногда C# код быстрее, чаще медлее но незначительно. S>Спасибо, друг. Ты второй раз спасаешь мой хрупкий мир от окончательного разрушения. S>А то как почитаешь КСВ, так дотнет рррвет всех и вся и уже на ассемблер посматривает.
Послушай, почему ты борешься с выдуманным противником? Покажи мне в этом топике хоть одного вменяемого, кто сказал что C# программа в общем случае быстрее Си++ программы?
Здравствуйте, VladD2, Вы писали:
NBN>>А что, тебе это разве не доказали? Особенно если не сравнивать бузину и дядьку в Киеве
VD>Где? Очень люблю смотреть на чудеса и фокусы .
Во-первых, вроде CreatorCray приводил ситуацию в которой хиповый аллокатор С++ обгонял GC.
Во-вторых, gandjustas любит забывать, про то что в С++ очень активно используется такие бесплатные по скорости стек и агрегирование объектов, что по логике существенно уменьшают потребные аллокации. Кроме того, он совсем забывает про спец аллокаторы, которые тоже могут очень неплохо повлиять на перформанс.
В-третьих, почему то совсем забывают, про то что деаллокации С++ проходят существенно более равномерно, нежели деаллокции GC. Сборка мусора с участием свопа — это то что сейчас выгнало меня на сайт
>> S>Ээээ.... Я на всякий случай хочу уточнить.... Правильно ли я понял, что код, переписанный на С#, в дотнет-стиле, работает на 20%-30% медленнее, чем тот-же код, написанный на С++ в С++ >> S>стиле.... Так? >> Зависит от теста. По моим личным наблюдениям, в среднем так. Иногда C# код быстрее, чаще медлее но незначительно. S>Спасибо, друг. Ты второй раз спасаешь мой хрупкий мир от окончательного разрушения. S>А то как почитаешь КСВ, так дотнет рррвет всех и вся и уже на ассемблер посматривает..
Не беспокойтесь — Ваш хрупкий мир надежно защищен стеной из предубеждений и ложных стереотипов.
Здравствуйте, adontz, Вы писали:
A>>>Программист на С# более эффективен чем на Си++, при одинаковых познаниях об архитеркуре ПО и в других не зависящих от ЯП сферах. NBN>>Более эффективен в чём? A>Быстрее реализуется ребуемую функциональность.
Ага, а требуемая функциональность в чём заключается? Ты не находишь что задачи бывают сильно разные. Допустим если тебе нужна прога (имеющая конкурентов) которая будет работать на покете и десктопе то уже лучше писать на С++.
NBN>>У нас есть схожий опыт.
A>Даже у меня есть схожий опыт. Вопрос в конкретных числах и в том, насколько корректно они получены.
Проблема в том, что по понятным обстоятельствам все эти опыты субъективны и голословны
Здравствуйте, NikeByNike, Вы писали:
NBN>Во-первых, вроде CreatorCray приводил ситуацию в которой хиповый аллокатор С++ обгонял GC.
NikeByNike, ну ты понимаешь сам, что есть разница между "доказал, что [почти] всегда быстрее" и "приводил ситуацию".
NBN>Во-вторых, gandjustas любит забывать, про то что в С++ очень активно используется такие бесплатные по скорости стек и агрегирование объектов, что по логике существенно уменьшают потребные аллокации. Кроме того, он совсем забывает про спец аллокаторы, которые тоже могут очень неплохо повлиять на перформанс.
Вообще-то, есть value-объекты, то есть структуры. Так что тут никаких функциональных преимуществ нет.
NBN>В-третьих, почему то совсем забывают, про то что деаллокации С++ проходят существенно более равномерно, нежели деаллокции GC. Сборка мусора с участием свопа — это то что сейчас выгнало меня на сайт
Блин, так это же и проблема! Время на деаллокации тратится не тогда, когда свободны ресурсы (on idle), а всегда.
Здравствуйте, adontz, Вы писали:
NBN>>Приятно, только чего-то никто кроме новичков не программирует. См. Spb и Paragon
A>Spb выпускает, фактически, хакерские программы. Зачем из .Net?
Не понял оба утверждения. И парагон пропущен.
И остальные игроки. По моим данным от шарпа чаще отказываются, нежели доделывают на нём продукты (авторитеты говорят что у таких продуктов форумы завалены недовольными пользователями).
Здравствуйте, NikeByNike, Вы писали:
A>>Быстрее реализуется ребуемую функциональность. NBN>Ага, а требуемая функциональность в чём заключается? Ты не находишь что задачи бывают сильно разные. Допустим если тебе нужна прога (имеющая конкурентов) которая будет работать на покете и десктопе то уже лучше писать на С++.
Нет не думаю. Я тебе даже больше скажу, у меня коммерческий продукт для покетов, который в первых трёх версиях был на Си++. Потом выяснилось, что писать его на Си++ (писать, тестировать, весь цикл) настолько дорого, что проще переделать на .Net. Так оно сейчас и есть, версия №4 на дотнете, все счастливы. Да, не тормозит. Вобщем-то, наверняка, замедление какое-то есть, но оно настолько несущественное, что длоя человека не заметно.
A>>Даже у меня есть схожий опыт. Вопрос в конкретных числах и в том, насколько корректно они получены. NBN>Проблема в том, что по понятным обстоятельствам все эти опыты субъективны и голословны
Проблема в том, что когда предлагаешь провести честное тестирование, все куда-то убегают.
Здравствуйте, VladD2, Вы писали:
NBN>>Приятно, только чего-то никто кроме новичков не программирует. См. Spb и Paragon
VD>Вообще-то еще как программируют. У меня вот Spb не стоит. А тройка программ написанных на CF стоит.
Всякое бывает. Популярных прог на CF лично я — не знаю.
VD>Spb занимаются надстройками на WM. Тут смысла в .NET почти нет, так как большая часть функциональности — это взаимодействие с С-шным API.
Spb занимается очень много чем, глянь на сайт.
VD>Но если надо писать логику и интерфейсы, то .NET CF очень даже удобное решение.
Нет, по уже указанным причинам, повторю:
1. тормозяв.
2. жруч.
3. требует установки дополнительного софта.
A>Если кто-то хочет организовать тестирование на более реальных задача буду рад помочь.
Я когда-то занимался мат.либой в довольно большом проекте. Когда появился SSE — появилась идея перевести математику на него. Каждую отдельную мат.функцию соптимизировали, проверили, что каждая функция действительно выполняется быстрее (не бенчмарктестах )? а потом запустили на ней проект — и суммарная скорость упала на 10%.
Я к тому, что реальные тесты проводить сложно и зависимости бывают довольно странные. Вот тестам подобным тем что ты привёл — я вообще не доверяю, ИМХО они практически бесмысленны.
Здравствуйте, adontz, Вы писали:
NBN>>Во-первых, вроде CreatorCray приводил ситуацию в которой хиповый аллокатор С++ обгонял GC.
A>NikeByNike, ну ты понимаешь сам, что есть разница между "доказал, что [почти] всегда быстрее" и "приводил ситуацию".
Не имеет смысла доказывать, я хотел показать, что задачи и применимость у GC и хипового аллокатора — достаточно разные.
Т.е. я совершенно спокойно соглашусь, что у типичного С++ хипового аллокатора средняя скорость работы будет меньше чем у GC из-за блокировок и алгоритмических причин.
Но, при этом у С++ значительно более богатый арсенал работы с памятью (стек, агрегация, спец.аллокаторы), что делает его в среднем более эффективным.
ИМХО очень странная идея сравнивать их напрямую.
NBN>>Во-вторых, gandjustas любит забывать, про то что в С++ очень активно используется такие бесплатные по скорости стек и агрегирование объектов, что по логике существенно уменьшают потребные аллокации. Кроме того, он совсем забывает про спец аллокаторы, которые тоже могут очень неплохо повлиять на перформанс.
A>Вообще-то, есть value-объекты, то есть структуры. Так что тут никаких функциональных преимуществ нет.
Вообще-то в шарпе они сильно убоги в сравнении с С++.
A>Блин, так это же и проблема! Время на деаллокации тратится не тогда, когда свободны ресурсы (on idle), а всегда. Это уже зависит от программиста и продукта.
Допустим в играх — аллокации (а иногда только одна глобальная аллокация) как правило проходят только при старте.
В критических местах, если не удаётся избежать аллокаций — деаллокации как правило откладываются.
Вобщем легкодоступных решений очень много и вот они как раз легко ловятся профилировщиком.
adontz wrote:
> Послушай, почему ты борешься с выдуманным противником? Покажи мне в этом топике хоть одного вменяемого, кто сказал что C# программа в общем случае быстрее Си++ программы?
В том то и дело, что общих случаев тут не вспоминается. Сплошные частные....
Здравствуйте, adontz, Вы писали:
A>Нет не думаю. Я тебе даже больше скажу, у меня коммерческий продукт для покетов, который в первых трёх версиях был на Си++. Потом выяснилось, что писать его на Си++ (писать, тестировать, весь цикл) настолько дорого, что проще переделать на .Net. Так оно сейчас и есть, версия №4 на дотнете, все счастливы. Да, не тормозит. Вобщем-то, наверняка, замедление какое-то есть, но оно настолько несущественное, что длоя человека не заметно.
Насколько я понял у тебя продукт это обёртка над базой данных?
Я уже говорил, что спорят люди работающие в разных областях
Я допустим раньше (и сейчас, но практически в качестве хобби) делал игры, а в последние года 4 специализируюсь практически на создании кроссплатформенных решений, где С++ практически безальтернативен.
A>Проблема в том, что когда предлагаешь провести честное тестирование, все куда-то убегают.
Ну я тоже убегу от конкретики,не буду же выносить внутренние наработки на публичный форум А личных — практически не имею.
Замечу, что год назад писал прототип десктопной программы, для прототипа выбрал именно шарп и написал на нём. Но если когда-нибудь решу доводить до релиза — перепишу на С++ для повышения конкурентоспособности.
Здравствуйте, NikeByNike, Вы писали: NBN>Я уже говорил, что спорят люди работающие в разных областях
Мне вот все споры С++ vs C# напоминают споры что лучше трактор или автобус.
Кто-то говорит: Трактор — отстой. Он мало людей перевозит и ездит медленно. А вот автобусом можно быстро много народу перевести.
А для бизнеса это очень хорошо.
Нет, отвечают ему, автобус никто из знакомых фермеров не использует, он плохо землю вспахивает,
да и после такой вспашки засеять не получается по-нормальному. Так что автобусы никому, абсолютно никому не нужны, они неэффективны.
VD>>Но если надо писать логику и интерфейсы, то .NET CF очень даже удобное решение. NBN>Нет, по уже указанным причинам, повторю: NBN>1. тормозяв. NBN>2. жруч. NBN>3. требует установки дополнительного софта.
Здравствуйте, WizardBox, Вы писали:
WB>Кто-то говорит: Трактор — отстой. Он мало людей перевозит и ездит медленно. А вот автобусом можно быстро много народу перевести. WB>А для бизнеса это очень хорошо. WB>Нет, отвечают ему, автобус никто из знакомых фермеров не использует, он плохо землю вспахивает, WB>да и после такой вспашки засеять не получается по-нормальному. Так что автобусы никому, абсолютно никому не нужны, они неэффективны.
Здравствуйте, criosray, Вы писали:
VD>>>Но если надо писать логику и интерфейсы, то .NET CF очень даже удобное решение. NBN>>Нет, по уже указанным причинам, повторю: NBN>>1. тормозяв. NBN>>2. жруч. NBN>>3. требует установки дополнительного софта.
C>Это не правда.
Это весьма банальный и даже печальный (для меня) факт.
Здравствуйте, NikeByNike, Вы писали:
A>>Spb выпускает, фактически, хакерские программы. Зачем из .Net? NBN>Не понял оба утверждения. И парагон пропущен.
Про парагон я просто не знаю, а значит лучше помолчу. Spb выпускает утилиты очень тесно взаимоджействующие с ОС, причём не всегда документированным способом.
NBN>И остальные игроки. По моим данным от шарпа чаще отказываются, нежели доделывают на нём продукты (авторитеты говорят что у таких продуктов форумы завалены недовольными пользователями).
Ага, ща ещё какие-то "авторитеты" появились.
Я думаю, не будет большой катастрофы, я если я тут опубликую часть внутренней переписки. Это по поводу Си++ на покете. Какие-то адреса поскипаны, некоторые письма перевены на русский, некоторые имена изменены. Очень показательно, между прочим. Когда такие люди начинаю своими кривыми руками писать на .Net, а потом хаять его, мне искрене обидно за .net.
Контекст: надо получить идентификатор покета чтобы автоматизировать лицензирование фронт-офиса Агент+. Идентификатор, естественно, должен быть такой же, как и в самой программе.
From: Roman Akopov
To: Giorgi Dolidze
Subject: Agent+ Pocket ID generation
Привет, Гиоргий!
Просто пометка, чтобы мы не забыли об этой задаче.
---------------------------------------------------------------- From: Giorgi Dolidze
To: Roman Akopov
Subject: Re:Agent+ Pocket ID generation
Рома, пересылаю последнее письмо Агент+ по поводу идентификаторов.
В данный момент ситуация такая:
> Здравствуйте, Гиоргий.
>
> Мы провели эксперименты с получением идентификатора КПК через настольное приложение.
> Нашли несколько вариантов получения идентификатора, но к сожалению,
> возвращаемые идентификаторы не совпадают с идентификатором, который
> показывает Агент+ в КПК. Т.е. не удалось найти аналогию функции
> получения идентификатора, которую мы используем внутри КПК.
> Возникла идея сделать простенькое приложение, которое запускается
> на КПК и заносит его идентификатор в реестр, чтобы потом значение
> этого ключа можно было прочесть настольным приложением. Но и тут
> столкнулись с проблемой. Функция GetDeviceUniqueID() (применение
> этой функии рекомендовала нам Microsoft), которую мы используем в
> C++ в КПК, возвращает другой идентификатор! Не такой же, как в
> Агент+! Оказывается, результат работы этой функции каким-то образом
> зависит от контекста приложения. Каким образом — не понятно. Что
> интересно, очередное обновление программы Агент+ (т.е. каждый новый
> релиз) на работу этой функции не влияет, она каким-то образом
> привязывается к неизменяемой части приложения.
> В итоге получается, что единственный способ узнать идентификатор
> КПК по примеру работы функции GetDeviceUniqueID() — это запустить в
> КПК приложение Агент+, и чтобы это приложение при старте сохранило в
> реестре КПК возвращенный этой функцией идентификатор. Так сейчас в программе и реализовано.
> Возможно, имеет смысл отказаться от использования функции
> GetDeviceUniqueID() в пользу какой-то другой (например, есть в КПК
> функция KernelIoControl() с параметром IOCTL_HAL_GET_DEVICEID, но
> эту функцию Microsoft не рекомендует к применению), но это чревато
> возникновением совпадений идентификаторов на разных КПК, с чем мы
> недавно столкнулись, почему и были вынуждены перейти на применение функции GetDeviceUniqueID().
---------------------------------------------------------------- From: Roman Akopov
To: Giorgi Dolidze
Subject: Re:Agent+ Pocket ID generation
Гиоргий!
Во-первых, либо они не так поняли, либо вы им не так объяснили задачу. Мне никогда не было надо узнавать идентификатор КПК из настольного приложения.
Во-вторых, всё что нужно, это точные параметры, которые они передают GetDeviceUniqueID. Точное знаение этих параметров. Результат работы этой функции зависит только от них и не зависит от какого бы то ни было "контекста приложения". Это явно описано в документации. Представитель Агент+ ошибается, утверждая что другое приложение, передающее функции GetDeviceUniqueID те же самые параметры получит другой идентификатор.
Таким образом, нет никакой необходимости тратить время на дополнительные эксперименты. Всё что нужно, это фрагмент кода, вызывающий функцию GetDeviceUniqueID.
---------------------------------------------------------------- From: Giorgi Dolidze
To: Roman Akopov
Subject: Re:Agent+ Pocket ID generation
Attachment: GetDevID.zip
Рома, пересылаю последнее письмо Агент+ по поводу идентицикаторов.
Жду от тебя какого-либо результата
> Здравствуйте, Гиоргий.
>
> Хорошо, вот фрагмент нашей функции получения идентификатора КПК (исходник предназначен для использования в приложении для Windows Mobile).
> Если будет получаться совпадающий идентификатор с нашей программой, пожалуйста, дайте знать.
---------------------------------------------------------------- From: Roman Akopov
To: Giorgi Dolidze
Subject: Re:Agent+ Pocket ID generation
Гиоргий!
Ну собственно всё как я и предполагал. Вот интересный нам кусок кода, всего две строки:
Так как речь о компиляторе Microsoft C++ , то строка "AgentPlus" равнозначна описанию
const char data[] = {'A', 'g', 'e', 'n', 't', 'P', 'l', 'u', 's', '\0'}
Как можно видеть из описания выше, реальная длина данных 10 байт, 9 байт видимых символов и десятый завершающий нулевой байт. В то же время размер данных, передаваемый функции GetDeviceUniqueID составляет 15 байт. Совершенно естественно, что функция GetDeviceUniqueID не имеет возможности проверить корректность данной информации. IsBadReadPtr в данном случае поможет мало, так как права на чтение будут выданы странице памяти целиком (обычно 4096 байт), а не 10 байтам строки. Кроме того, после строки "AgentPlus" в памяти находятся данные других строковых констант программы.
Таким образом, элементарнейший анализ исходного кода показывает, что функция GetDeviceUniqueID получает в качестве входного параметра не только 10 запланированных байт, но и ещё 5 совершенно случайных байт информации, содержимое которых непредсказуемо.
Справедливости ради надо заметить, что ссылочные константы, коими являются строки, располагаются в памяти последовательно и всё не так уж непредсказуемо. Так, если говорить о версии программы к которой я имел доступ, строка "AgentPlus" располагается по смещению 0x14BF68 в файле AgentPlus.exe и по смещению 0xAF68 в секции '.data'. Следующий за ней 5 байт это 2 нулевых байта выравнивания до 4байтовой границы и первые три байта юникодной строки "GetDeviceUniqueID" в кодировке UTF16: 'G', '\0', 'e'. Таким образом полностью, фактически передаваемый паарметр выглядит как
const char data[] = {'A', 'g', 'e', 'n', 't', 'P', 'l', 'u', 's', '\0', '\0', '\0', 'G', '\0', '\e'}
Моя рекомендация заключается в том, чтобы
1) Исправить указанную выше ошибку. Передавать в функцию указатель на Луну далеко не самая хорошая идея.
2) Добиться совместимости с предыдущими версиями.
Обеих целей можно добиться коррекцией строки №3 файла GetDevID.cpp. Для этого необходимо заменить
#define APPLICATION_DATA "AgentPlus"
на
#define APPLICATION_DATA "AgentPlus\0\0\0G\0e"
Сопроводив эту странную константу поясняющим комментарием, дабы в дальнейшем она не подвергалась модификациям.
Что это доказывает? Конкретно данный случай сам по себе — ничего, но подробных ошибок я видел множество. Что интересно, это не просто production код, люди исследовали этот код, пытались воспроизвести функциональность, а ошибка всё равно ускользнула. Подобные моменты совсем не связаны с программированием бизнес-логики, это оверхед программирования на Си++, который не покроешь автоматизированными тестами.
Поэтому, везде где допустимо — managed среды. Так спокойнее. Буду я покупать бизнес-приложение на Си++? Нет! Игры, CD ejector'ы, научные расчёты пишите на Си++. Деньги я Си++ просто не доверю. Какой-то дурак сорвёт стек, а мне с налоговой разбираться. Очень надо. А дурак будет, доказано Zanussi.
Здравствуйте, adontz, Вы писали:
A>Про парагон я просто не знаю, а значит лучше помолчу. Spb выпускает утилиты очень тесно взаимоджействующие с ОС, причём не всегда документированным способом.
Может быть половину из них.
NBN>>И остальные игроки. По моим данным от шарпа чаще отказываются, нежели доделывают на нём продукты (авторитеты говорят что у таких продуктов форумы завалены недовольными пользователями). A>Ага, ща ещё какие-то "авторитеты" появились.
Ну я не знаю как назвать людей которые принимали решения по поводу используемых технологий.
A>Я думаю, не будет большой катастрофы, я если я тут опубликую часть внутренней переписки. Это по поводу Си++ на покете. Какие-то адреса поскипаны, некоторые письма перевены на русский, некоторые имена изменены. Очень показательно, между прочим. Когда такие люди начинаю своими кривыми руками писать на .Net, а потом хаять его, мне искрене обидно за .net. A>Контекст: надо получить идентификатор покета чтобы автоматизировать лицензирование фронт-офиса Агент+. Идентификатор, естественно, должен быть такой же, как и в самой программе.
A>
A>[b]From: Roman Akopov
A>Обеих целей можно добиться коррекцией строки №3 файла GetDevID.cpp. Для этого необходимо заменить
A>#define APPLICATION_DATA "AgentPlus"
A>на
A>#define APPLICATION_DATA "AgentPlus\0\0\0G\0e"
A>Сопроводив эту странную константу поясняющим комментарием, дабы в дальнейшем она не подвергалась модификациям.
Это какая-то уж очень ламерская ошибка...
A>Поэтому, везде где допустимо — managed среды. Так спокойнее. Буду я покупать бизнес-приложение на Си++? Нет! Игры, CD ejector'ы, научные расчёты пишите на Си++. Деньги я Си++ просто не доверю. Какой-то дурак сорвёт стек, а мне с налоговой разбираться. Очень надо. А дурак будет, доказано Zanussi.
Ну это дело твоё. Но ты опять не учитываешь одну вещь — я не против того что быстрые/утилитарные бизнеспроги имеет смысл писать на шарпе/яве, даже для покетов. Там где конкуренция вынуждает писать быстро — шарп самое то. Однако если конкуренция вынуждает писать качественно, если у тебя есть (готов потратить) время на тестирование — пишут на С++. А иначе — не будут брать
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, VladD2, Вы писали:
NBN>>>А что, тебе это разве не доказали? Особенно если не сравнивать бузину и дядьку в Киеве
VD>>Где? Очень люблю смотреть на чудеса и фокусы .
NBN>Во-первых, вроде CreatorCray приводил ситуацию в которой хиповый аллокатор С++ обгонял GC.
Я видимо не заметил его.
Это должен быть прикольный фокус, так как:
1. Очень тяжело обогнать операцию инкремента. Особенно если учесть, что паять GC выделяет последовательно и у него нет проблем с фрагментацией.
2. Само понятие "аллокатор С++" вещь чертовски интересная. Ведь разные библиотеки используют разные кучи. Скажем, библиотеки VC 7 точно использовали виндовый хип по умолчанию. А он уже может работать по разному на разных машина.
NBN>Во-вторых, gandjustas любит забывать, про то что в С++ очень активно используется такие бесплатные по скорости стек и агрегирование объектов, что по логике существенно уменьшают потребные аллокации.
Не будем обсуждать что забывает тот или иной товарищ.
Согласен, что С++ позволяет реже обращаться к хипу, а при желании конкретно химичить.
Но разговор же был о скорости куч (хипов). И тут все виденные мною С++-ные реализации конеретно сливают дотнетному GC. По крайней мере до тех пор пока в системе достаточно памяти.
NBN> Кроме того, он совсем забывает про спец аллокаторы, которые тоже могут очень неплохо повлиять на перформанс.
Мне кажется он ни про что не забывает. Он просто говорил про то, что есть по умолчанию и то, что используется в 99% программ — про стандартные реализации куч.
Вы исходите из разных отпавных точек.
Он рассказывает вам, что GC весьма эффективен и в большинстве случаев управляемые программы ничем не уступает тем что пишутся на С++. А вы ему в ответ рассказываете, что С++ при желании предоставляет больший просто для оптимизаций.
Вы оба правы. Как, в прочем, оба и не правы.
NBN>В-третьих, почему то совсем забывают, про то что деаллокации С++ проходят существенно более равномерно, нежели деаллокции GC. Сборка мусора с участием свопа — это то что сейчас выгнало меня на сайт
Вот сейчас ты сказал чушь. Чтобы понять почему это так, стоит прочесть внятное описание алгоритмов работы ЖЦ и стандартной реализации кучи С.
Если в кратце, то ЖЦ вообще не освобождает память. Он выявляет и спасает живые объекты. А стандартные кучи основаны на связанных списках и в некоторых случаях (при сильной фрагментации и хаотичности операций занятия и освобождения памяти) может приводить к очень нелинейной скорости освобождения объектов.
Есть и улучшенные реализации куч. Но они обычно чем-то жертвуют (памятью, скоростью выделения памяти).
На самом деле очень трудно сказать какой из подходов быстрее в реальных задачах. Кучи С могут отлично показывать себя в одних задачах и сливать в других. Как раз заем множества мелких объектов с хаотичным освобождением — это не для С-кучи.
ЖЦ тоже может показывать плохое поведение. Особенно критично для ЖЦ когда в системе недостаточно памяти. В этом случае ЖЦ начинает урезать свои кучи, но это резко замедляет его алгоритмы. Самый плохой случай для ЖЦ — это свопинг.
Самое смешное, что те кто ругает ЖЦ даже не знают в чем его реальные слабые места. Скажем ты знаешь что такое барьер записи?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, NikeByNike, Вы писали:
VD>>Но если надо писать логику и интерфейсы, то .NET CF очень даже удобное решение. NBN>Нет, по уже указанным причинам, повторю: NBN>1. тормозяв. NBN>2. жруч. NBN>3. требует установки дополнительного софта.
Ну, ты упертый .
Я тебе русским языком говрю: три программы... не тормозят... не жрут... ничего не требуют, так как CF на WM6 уже установлен. Сам писал под CF особых проблем не испытал. Главная проблема не в тормозах или прожорливости, а в том, что CF имеет более убогий API. Там ногого нет, что есть в полноценном фрэймворке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
