Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Utruk, Вы писали:
U>>Естественно вместе с GC.Collect, потому как объектов много и память физическая нужна сейчас, а не когда-нибудь.
E__>Вызов GC.Collect() совершенно не гарантирует, что запустится сборка мусора.
Здравствуйте, gandjustas, Вы писали: G>Чуть более реальный сценарий, как раз выделение-освобождение памяти. G> [...] G>Результаты: G>C# time 164 G>Delphi time 484
G>ЗЫ. При написании тестов запетил, что .NET тормозит при перераспределении больших блоков памяти. Поэтому большим спискам и StringBuilder с кучей текста лучше сразу выставлять capicity и не превышать её.
Ага... поигрался с ObjectCount... где-то от 10000 до 20000 происходит тот самый знаменательный момент под названием сборка мусора и все... производительность программы на C# умерла, после этого она уже медленнее всегда. По моему 20000 объектов — более чем реальное распределение за один заход, зависит конечно от задачи...
Здравствуйте, diatlov, Вы писали:
D>Т.е. если я скопировал прогу на конечный компьютер и она нихрена не работает, то значит забить на это и сказать "переставляй винду дядя"?
Нет, это значит, что если полазал в настройках грязными ручками, то нечего на дотнет пенять.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Utruk, Вы писали:
U>>Я честно говоря уже не очень хорошо помню конкретные цифры которые замерялись, но в среднем от одного клиента в зависимости от характера выполняемой задачи приходил один запрос с интервалом в 2..3 минуты. Каждый клиент работал примерно две смены из трех. Кроме того в систему равномерно влетало примерно 20..40 тысяч документов в сутки (1 документ — 1 запрос). Время обработки одного запроса от мгновенного (ну там сотни миллисекунд) до секунд 5 (когда они наваливались на сервер). Естественно приоритет работы пользователей был наивысшим, если чо фоновым процессам показывался кукишь и они отыгрывались на сервере по ночам, когда пользователей было мало. G>Вполне терпимая нагрузка на один неочень мощный сервак.
А я про что? 80000 — ничего экстраординарного, а 7000 это скорее от незнания чем занимается сервер, нулей много но ни о чем не говорит.
Здравствуйте, gandjustas, Вы писали:
kuj>>>Delphi как была никчемной игрушкой для бедных ВУЗов и энтузиастов этого уродства под названием "delphi language", так ею и осталась. U>>Вот опустили... а я то тут в мелкой конторке маюсь с оборотом в USD $7M/год и клиентурой от Германии до Японии. G>Это премущество делфи?
Это имеет ровно-то же отношение к вопросу хороша делфи или плоха как и пассаж выше про игрушку для вузов и т.п... Фирма (вполне себе успешная) в которой я сейчас работаю пользуется Delphi с пятой версии... ни на ВУЗ с бедными студентами ни на уродство оно непохоже...
Здравствуйте, Utruk, Вы писали:
U>Здравствуйте, gandjustas, Вы писали: G>>Чуть более реальный сценарий, как раз выделение-освобождение памяти. G>> [...] G>>Результаты: G>>C# time 164 G>>Delphi time 484
G>>ЗЫ. При написании тестов запетил, что .NET тормозит при перераспределении больших блоков памяти. Поэтому большим спискам и StringBuilder с кучей текста лучше сразу выставлять capicity и не превышать её.
U>Ага... поигрался с ObjectCount... где-то от 10000 до 20000 происходит тот самый знаменательный момент под названием сборка мусора и все... производительность
программы на C# умерла, после этого она уже медленнее всегда. По моему 20000 объектов — более чем реальное распределение за один заход, зависит конечно от задачи...
Тотже код.
Поставил ObjectCount = 1000000
C# time 53285
Delphi time 63937
Проект на C# собирал в режиме release, запускал не из студии. В BDS оптимизация включена.
Здравствуйте, Utruk, Вы писали:
U>>>Я честно говоря уже не очень хорошо помню конкретные цифры которые замерялись, но в среднем от одного клиента в зависимости от характера выполняемой задачи приходил один запрос с интервалом в 2..3 минуты. Каждый клиент работал примерно две смены из трех. Кроме того в систему равномерно влетало примерно 20..40 тысяч документов в сутки (1 документ — 1 запрос). Время обработки одного запроса от мгновенного (ну там сотни миллисекунд) до секунд 5 (когда они наваливались на сервер). Естественно приоритет работы пользователей был наивысшим, если чо фоновым процессам показывался кукишь и они отыгрывались на сервере по ночам, когда пользователей было мало. G>>Вполне терпимая нагрузка на один неочень мощный сервак.
U>А я про что? 80000 — ничего экстраординарного, а 7000 это скорее от незнания чем занимается сервер, нулей много но ни о чем не говорит.
Зато создание 100 млн объектов это очень о многом говорит. В дилетантстве ты уже расписался. Можешь больше не стараться.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, это значит, что если полазал в настройках грязными ручками, то нечего на дотнет пенять.
Тебе не кажется что все твои доводы безосновательны?
Да, если программа на .NET не использует сетевых возможностей, не лезет узнавать сетевое имя твоего компа, не открывает лишние подозрительные порты и т.д. (т.е. если программа для домохозяек, дает совет что лучше на завтрак приготовить) то она таки будет работать на любом компьютере с предустановленным фреймворком без дополнительных напильников.
У меня программа активно юзает сеть и мне таки пришлось полазить в настройках, но уже после того как exception стал вылезать на конечной машине.
В общем, если у тебя нет опыта дистрибуции и распространения программ на .NET, то уж лучше молчи, а если есть то скажи конкретно какую галочку и где надо поставить при сборке чтобы все работало всегда и везде.
НС>>Нет, это значит, что если полазал в настройках грязными ручками, то нечего на дотнет пенять.
D>Тебе не кажется что все твои доводы безосновательны? D> Да, если программа на .NET не использует сетевых возможностей, не лезет узнавать сетевое имя твоего компа, не открывает лишние подозрительные порты и т.д. (т.е. если программа для домохозяек, дает совет что лучше на завтрак приготовить) то она таки будет работать на любом компьютере с предустановленным фреймворком без дополнительных напильников. D>У меня программа активно юзает сеть и мне таки пришлось полазить в настройках, но уже после того как exception стал вылезать на конечной машине.
D>В общем, если у тебя нет опыта дистрибуции и распространения программ на .NET, то уж лучше молчи, а если есть то скажи конкретно какую галочку и где надо поставить при сборке чтобы все работало всегда и везде.
У меня много лет опыта дистрибуции программ на .NET и подобной проблемы ни разу не видел. "Что я делаю не так?"
Здравствуйте, diatlov, Вы писали:
D>Тебе не кажется что все твои доводы безосновательны?
Нет.
D> Да, если программа на .NET не использует сетевых возможностей, не лезет узнавать сетевое имя твоего компа, не открывает лишние подозрительные порты и т.д. (т.е. если программа для домохозяек, дает совет что лучше на завтрак приготовить) то она таки будет работать на любом компьютере с предустановленным фреймворком без дополнительных напильников.
Несколько программ, которые я пишу за деньги, "активно юзают сеть". И еще ни разу не было проблем с CAS. Более того, в отличие от тебя, я неплохо представляю себе всю механику CAS и как оно работает, а не просто пользуюсь магической строкой с caspol.exe.
D>В общем, если у тебя нет опыта дистрибуции и распространения программ на .NET, то уж лучше молчи
D>, а если есть то скажи конкретно какую галочку и где надо поставить при сборке чтобы все работало всегда и везде.
Галочку надо ставить не при сборке, а в мо... Надо привести в оригинальное состояние локальные политики пользователя и машины на той машине, где у тебя странным образом срабатывает CAS (и корпоративную политику, если она используется).
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Галочку надо ставить не при сборке, а в мо... Надо привести в оригинальное состояние локальные политики пользователя и машины на той машине, где у тебя странным образом срабатывает CAS (и корпоративную политику, если она используется).
Т.е. взял человек мою программу, а у него там политиков понастроено. Я должен ему сказать: "Извини чел, у тебя компьютер супермегазащищен, перенастрой его так чтобы моя программа не ругалась". Так? Или мне все таки класть в дистрибутив caspol и автоматически при установке регить прогу?
Здравствуйте, diatlov, Вы писали:
D>Т.е. взял человек мою программу, а у него там политиков понастроено. Я должен ему сказать: "Извини чел, у тебя компьютер супермегазащищен, перенастрой его так чтобы моя программа не ругалась". Так?
Так. А ты чего думаешь, я твою программу на Дельфи не поставлю раком несколькими кликами мышки?
D> Или мне все таки класть в дистрибутив caspol и автоматически при установке регить прогу?
Нет, проблемы поставленной раком операционки это проблемы того, кто поставил ее раком.
Здравствуйте, diatlov, Вы писали:
D>Обсудим все + и — ?
Для меня два главных, и пока никак не решаемых, минусов дельфи:
1) полное отсутствие возможности создания программ с векторным графическим интерфейсом м поддержкой автоматической компоновки;
2) убогая (точнее очень устаревшая) модель работы с БД. Нафига нужен весь этот путь DataSet — DataSource — DataLink — DB-aware controls? Почему просто нельзя подключить произвольный объект к стандартному визуальному контролу? Нет, блин, до сих пор городим две иерархии контролов, датасеты, которые нужно обязательно открыть перед тем как что-то в них вставить, и к которым невозможно привязать два грида с независимым перемещением и т.п.
По иронии судьбы, всё это добро в довольно изящной форме реализовано в WPF и FCL C# 3.5.
Здравствуйте, diatlov, Вы писали: D>Т.е. взял человек мою программу, а у него там политиков понастроено. Я должен ему сказать: "Извини чел, у тебя компьютер супермегазащищен, перенастрой его так чтобы моя программа не ругалась". Так?
Вообще говоря — да.
Потому, что скорее всего нерабочесть твоей проги — это не досадная случайность, а осознанное решение местного админа.
И это решение нужно уважать. Админ имеет полное право ограничить исполнение всякого отстоя, поступившего неизвестно откуда. D>Или мне все таки класть в дистрибутив caspol и автоматически при установке регить прогу?
Вот автоматически — не надо. Галочку в инсталлере сделать можно, предупредив админа о причинах необходимости работать под full trust.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Utruk, Вы писали:
U>Есть некий механизм финализации объекта который состоит из двух фаз: U>1) когда объект больше не нужен производятся некие действия. U>2) память зарезервированная под объект освобождается.
Это заблуждение. Пункта 2 в GC-based системах просто нет. Точнее, в классических менеджерах памяти освобождение — это возврат использованной памяти обратно в хип. В GC в хип возвращается целое поколение, что намного эффективнее пообъектного освобождения.
Далее, про эффективность финалайзеров в управляемой среде вообще рассуждают только новички. Потому, что в реальной системе объектов с финалайзерами — незаметная доля процентов. Подавляющему большинству объектов финалайзеры не нужны. То есть п.1. неприменим.
U>Поясню ближе к практике. У меня есть некий процесс, результатом выполнения которого является сложная динамическая структура. Структура состоит из неопределенного количества объектов — порядок деятки, сотни тысяч, миллионы объектов. Эта структура может создаваться как результат некоего процесса, сохраняться в БД (в БД этих структур естественно может быть не одна), загружаться оттуда, части её могут модифицироваться или удаляться, причем удаляться именно в памяти чтобы сгенерироваться снова из базы или из процесса. Меня волнует вопрос, насколько быстро это всё будет происходить.
Это будет происходить очень быстро. Потому, что выделение памяти в дотнете стоит примерно столько же, сколько выделение на стеке — такой же инкремент указателя. Удаление объектов не делается вообще.
U>Делаем простой тест — распределяем миллион (два, десять) объектов и видим что не смотря на заявления про супер быстрый манагер памяти, про то что кто-то там генерит код более быстрый чем нативный Delphi, реально объекты были созданы существенно медленнее. С удалением объектов картина очень похожая.
У тебя косячный бенчмарк.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Utruk, Вы писали: U>Нет. Я хочу поговорить о том с какой скоростью мой процесс будет получать очередную серию кусков памяти. С этого всё начиналось. Меня вполне удовлетворит если это случиться быстрее чем на Delphi.
Да, это таки случится быстрее, чем на Delphi.
Есть некоторые вырожденные сценарии, когда GC будет менее эффективным, но в жизни их получить достаточно тяжело.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это будет происходить очень быстро. Потому, что выделение памяти в дотнете стоит примерно столько же, сколько выделение на стеке — такой же инкремент указателя. Удаление объектов не делается вообще.
А что мешает сделать то же самое в нативном коде? В старом добром Паскале PDP-11 были аналогичные функции работы с памятью (если склероз не изменяет, назывались Mark/Release). В Турбопаскале они не были реализованы видимо по причине сегментной организации памяти в DOS, но при плоской модели памяти проблем с их реализацией никаких.
---
The optimist proclaims that we live in the best of all possible worlds; and the pessimist fears this is true