Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Шахтер, Вы писали:
Ш>>Заведи глобальный счетчик дорогих объектов. Как только этот счетчик превысит некоторое пороговое значения -- вызывай GC (в конструкторе класса).
VD>Лучше этого не делать. В МС и так занимаются магией для хэндлов. Погляди под Рефлектором класс System.Runtime.InteropServices.HandleCollector. А воспользоваться им можно через System.Runtime.InteropServices.HandleCollector.
Не совсем понял. Ты имеешь ввиду, что делать этого не нужно, потому что MS уже обо всём позаботилась, или будут какие-то негативные побочные эффекты?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Есть объекты с детерминирванным временем жизни. CS>>Детерменированность как информация это то качество которое мы теряем при отданнии их на откуп GC.
IT>Не могу согласиться с этим утверждением. Время жизни объектов в системах с GC вполне детерминировано и определяется наличием живых ссылок на этот объект.
Здравствуйте, Шахтер, Вы писали:
Ш>Не совсем понял. Ты имеешь ввиду, что делать этого не нужно, потому что MS уже обо всём позаботилась, или будут какие-то негативные побочные эффекты?
Для хэндлов ОС обернутых в объекты ничего делать не надо. Для своих объктов нужно зарегистрировать соотвествующий объем памяти и отрегистрировать в финалайзере/диспозе.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Фигачешь по битмапу как хочешь, а потом битбильдом... А можно просто отключить битмап от контекста порисовать и подключить обратно.
VD>Просто не эффективно ведь по пиксельно рисовать.
Очень смешно... Ты пробовал?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Все слова про объекты и их экономию просто смехотворны. За время отрисовки таких объектов может возникнуть, ну, десятки, ну, сотни, в параноидальных случаях тысячи. Все это для GC не цифры.
Ты понимаешь, какая фигня получается... У меня есть простейшая задача — рисовать линии (MoveTo/LineTo, простые, однопиксельные). Но рисовать мне их надо в общем случае каждый раз другим цветом. А для этого надо создавать/удалять "карандаши" каждый раз. Линия рисуется очень быстро, а вот "карандаш" — дорогого стоит, примерно как 100 линий, если не больше. Это яркий пример "обобщенной абстракции", за которую следует немедленно отвинчивать яйца с особым цинизмом — ламеры интерфейс дизайнили. Но дело не в этом. Для GC это конечно же не цифры, но сами объекты жутко дороги по времени, а GC об этом не знает и знать не может.
Но это я уже увел в сторону. Начинать надо с того, что концепция "кистей и карандашей" полностью себя дискредитировала и не подходит в качестве примеров для управления памятью.
На самом деле, malloc/free не очень-то подходит для сожительства с GC. А вот концепция RAII — вполне подходит.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению. Ты вчитывался в код который привел c-smile? Погляди внимательно на фрагменты вроде: VD>
VD>Заметь. Ни о каком кэшировании c-smile не заикался. Сталобыть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению стрых. Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
setBrush может делать кеширование HBRUSH внутри (а может и не далать ибо brush это lightweight object) — это его бизнес.
В данном случае это изоляция деталей. Для сред типа Java UI и C# наличиие отдельных объектов
типа CBrush не нужно в 99% случаев. Библиотека более компактная и универсальная получается.
Более того если ты захочешь иметь скажем AggGraphics: public Graphics {}
то такая организация сильно упрощает жизнь.
Меньше базовых (примитивных) классов — меньше головных болей во многих смыслах.
Имхо ошибка Framework состоит в том что там на каждый чих по классу.
Как я уже говорил количество оных приближается к критической отметке детерминированного хаоса.
VD>>Заметь. Ни о каком кэшировании c-smile не заикался. Сталобыть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению стрых. Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
CS>setBrush может делать кеширование HBRUSH внутри (а может и не далать ибо brush это lightweight object) — это его бизнес.
И еще, например для solid/gradient brush я HBRUSH вообще не создаю.
И есть еще такая штука как DC solid brush — см. SetDCBrushColor.
То же самое справедливо для Pen — они тоже не всегда создаются. Например
прямоугольник с бордюрами и заливкой не требует создания pen при рисовании.
Такая организация безообъектгого рисования поднимает в разы скорость вывода на наиболее частых случаях — именно тех
котрые нужно оптимизировать.
VD>Еще раз повторяю, что подход c-smile-а — это вообще создание всех ресурсов на один раз. И все чтобы сэкономить по 8 байт на объект (не создавать его в хипе).
Здравствуйте, VladD2, Вы писали:
VD>Разница между оптимизацией по Дворкину и оптимизацией джита заключается в том, что в одном случае он будет делать ее руками накосячив и сделав не то что нужно, а во втором случае это будет продуманная оптимизация джита. При этом она гарантированно не будет влиять на результаты вычисений.
Все-бы хорошо в твоих рассуждениях, но вот расчитывать на то, что оптимизатор от MS в принципе не может "накосячить" (выражаясь по фене) — это, мягко говоря, весьма опрометчиво. "Гестапа сильно ругалась"
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Все-бы хорошо в твоих рассуждениях, но вот расчитывать на то, что оптимизатор от MS в принципе не может "накосячить" (выражаясь по фене) — это, мягко говоря, весьма опрометчиво. MS>"Гестапа сильно ругалась"
1. Речь пока что идет о Яве.
2. Ты сам-то пробовал код по этой ссылке тестировать? У меня пустой экран получается.
3. Под гарантией я подразумеваею предсказуемость результата. То есть речь идет о том, что это логически доказуемая оптимизация.
Ну, а накосячить можно и в куда более простых местах.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
VD>>Еще раз повторяю, что подход c-smile-а — это вообще создание всех ресурсов на один раз. И все чтобы сэкономить по 8 байт на объект (не создавать его в хипе).
CS>Это где я токе говорил?
Здравствуйте, c-smile, Вы писали:
CS>setBrush может делать кеширование HBRUSH внутри (а может и не далать ибо brush это lightweight object) — это его бизнес.
Он lightweight пока их 2-3. А 100 уже будет заметна. К тому же кисти бывают не только solid, но и разные градиентные...
CS>В данном случае это изоляция деталей. Для сред типа Java UI и C# наличиие отдельных объектов типа CBrush не нужно в 99% случаев. Библиотека более компактная и универсальная получается.
Объекты нужны программистам. А компоютеру вообще хватило бы маш-кода без всяких там функций.
Мне лично такой подход не нравится. При этом подход, как я понял, оправдывается лучшим управлением памятью. Вот я и говорю, что память отведенная под объекты вроде шрифтов и кистей при отрисовке погоды не сделает. А вот пересоздание шрифтика может замедлить скорость отрисовки в разы. Так что о чем идет речь в тематическом сообщении я вообще понять не могу.
CS>Более того если ты захочешь иметь скажем AggGraphics: public Graphics {} CS>то такая организация сильно упрощает жизнь.
Я хочу иметь упрощенную жизнь не при разработке библиотеки, а при ее использовании.
CS>Меньше базовых (примитивных) классов — меньше головных болей во многих смыслах. CS>Имхо ошибка Framework состоит в том что там на каждый чих по классу. CS>Как я уже говорил количество оных приближается к критической отметке детерминированного хаоса.
Опять двадцать пять. Нет проблем в классах и объектах. Есть проблемы в грамотном кэшировании и оптимизациях. Учитывая же, что GDI+ библиотека сишная и к фрэймворку отношения не имеющая, не трудно понять насколко становятся разумны разговоры об управляемых объектах в контексте вывода графики через С++-библиотеку.
В общем, давай так. Ты утверждашь, что проблемы со скоростью отрисовки в Яве и дотнете связаны с тем, что в GUI-библиотеках слишком много классов и соотвественно объектов. Так? Тогда как ты объяснишь, тот факт, что даже тысячи объектов пересоздаются Явой и дотнетом (за последнего зуб даю) в мгноверие ока?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>И еще, например для solid/gradient brush я HBRUSH вообще не создаю.
CS>И есть еще такая штука как DC solid brush — см. SetDCBrushColor.
А что делать со шрифтами? Или для них объекты содавать можно?
Ну, и за одно причем тут объекты то? Если кисть создается быстро, то в объекте Brush можно не держать хэндлов, а создавать их перед каждой отрисовкой. Но при этом я смогу запихать кисть в нужное мне свойство и оперировать им как с объектом.
В общем, еще раз... Чем тебе не угадили объекты?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Ты понимаешь, какая фигня получается... У меня есть простейшая задача — рисовать линии (MoveTo/LineTo, простые, однопиксельные). Но рисовать мне их надо в общем случае каждый раз другим цветом. А для этого надо создавать/удалять "карандаши" каждый раз. Линия рисуется очень быстро, а вот "карандаш" — дорогого стоит, примерно как 100 линий, если не больше.
Вот расскажи об этом c-smile, а то он утверждает, что кисти и карандаши очень дешевы. Видимо вы их в разных количествах используете.
MS> Это яркий пример "обобщенной абстракции", за которую следует немедленно отвинчивать яйца с особым цинизмом — ламеры интерфейс дизайнили. Но дело не в этом. Для GC это конечно же не цифры, но сами объекты жутко дороги по времени, а GC об этом не знает и знать не может.
Ты точно мое сообщение до конца дочитал? Позволю себе процетировать себя:
Я вот опробовал другую идею. В Graphics кэшируются реальные ресурсы выделяемые ОС. А все объекты вроде Font, Brash и т.п. только хранят их описание. Внутри Graphics имеются банальные хэш-таблицы ассоциирующие эти объекты с хэндлами ОС. ...
Мы как бы на одних позициях с тобой стоим.
MS>Но это я уже увел в сторону. Начинать надо с того, что концепция "кистей и карандашей" полностью себя дискредитировала и не подходит в качестве примеров для управления памятью.
Тут тебе конечно виднее. Видимо ты прав. Но как это относится к теме и моей на нее реакции?
MS>На самом деле, malloc/free не очень-то подходит для сожительства с GC. А вот концепция RAII — вполне подходит.
То же не спорю. В общем, не могу понять споришь ты со мной или соглашаешся.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>И еще, например для solid/gradient brush я HBRUSH вообще не создаю.
CS>>И есть еще такая штука как DC solid brush — см. SetDCBrushColor.
VD>А что делать со шрифтами? Или для них объекты содавать можно?
Да все что угодно. Хочешь создавай, хочешь нет.
В 99% приложений таблица фонтов вообще полу-статическая.
Создаются динамически но освобождаются вместе с завершением процесса.
VD>Ну, и за одно причем тут объекты то? Если кисть создается быстро, то в объекте Brush можно не держать хэндлов, а создавать их перед каждой отрисовкой. Но при этом я смогу запихать кисть в нужное мне свойство и оперировать им как с объектом.
Еще раз. Сделай сам себе объекты-описатели с нужным тебе набором свойств если тебе надо.
Только свой собственный и сугубо managed сиречь работающий в режиме fire-n-forget.
VD>В общем, еще раз... Чем тебе не угадили объекты?
Да мне лично они до лампочки. Я framework не использую в т.ч. по причинам изложенным — плохо спроектирован.
Я (и мы все здесь) пытаюсь понять в чем беда Java и .NET GUI?
Мысли я свои изложил.
Концепт "все в managed" в реальности выливается в то что на самом деле
unmanaged хэндлами засеян весь фреймворк квадратно гнездовым образом.
Такое впечатление что:
Проектировщики WinForms либо допустили банальную архитектурную ошибку — еще раз встали на те же грабли что и Java.
Либо изначально это все и не было раcчитано на эффективную работу.
