Здравствуйте, VladD2, Вы писали:
ANS>>Он таки резиновый, хотя, естественно, и ограничен доступной памятью, в языках, в которых стек это деталь реализации. Например, кадры активации в ST, могут для скорости работы мапится на стек, а при исчерпании такового, "материализоваться" в полноценные объекты и переезжать в кучу, освобождая стековое пространство.
VD>Это если где-нить внизу не попадется неуправляемый стековый фрэйм.
Хм. Интересный вопрос. Ситуация маловероятная, но всё же... Нужно уточнить.
Здравствуйте, c-smile, Вы писали: S>>Я так понимаю, что ты ожидаешь от SetLineColor/SetFillColor пулеметной скорострельности, по сравнению с CreatePen/SelectPen. Так? Это нигде не прозвучало в явном виде, но судя по наездам на создание карандашей ты считаешь именно так.
S>>А теперь я хочу спросить — а почему, собственно, ты так думаешь? Я вот не могу понять, почему операция CreatePen+SelectPen должна быть намного дороже чем SetLineColor. В случае однотонного карандаша, естественно. В чем такая уж существенная разница? Благодаря какой магии мы экономим внутрях SetLineColor? Пока что я вижу два вызова вместо одного. Хм, может, оно будет чуть-чуть дороже. Но на том же уровне наивности поочередное рисование двумя сложными карандашами будет быстрее в случае отдельного создания. Потому что по логике SetLinePattern() делает то же самое, что и CreatePatternPen()+SelectPen(), но каждый раз. А CreatePatternPen() мы можем вынести за пределы цикла.
CS>CreatePen аллоцирует нечто ассоциированное с handle в таблице . Но если посмотреть внимательно CS>то ни один тип Pen в GDI не требует ничего особо военного — того что можно CS>было бы экономить при создании. CS>LOGPEN проста как двери и имплемнтация SetPen(Style, Width, Color) тривиальна — установка текущих CS>регистров типа линии.
CS>Более того в GDI нет ни одной функции берущей на вход HPEN кроме SelectObject.
CS>Вопрос: зачем надо сначала создавать pen, потом его select, а потом destroy? CS>В чем сермяжность?
Ну, это не ответ на мой вопрос. Раз у нас LOGPEN проста как двери, то что мы теряем? Теоретически, в следующих версиях винды LOGPEN может оказаться безумно сложным, и его создание будет настолько дорогостоящим удовольствием, что лучше дать разработчику возможность вручную контролировать кэширование этих объектов. Использование двухстадийной схемы в той же теории позволяет максимизировать скорость переключения карандашей, вынеся создание за скобки.
И все таки я возвращаюсь к своему исходному вопросу: почему вызов Create-Select-Destroy настолько дороже, чем SetPen()? Ну пусть он будет в три раза дороже — не жалко. Хотя я очень сомневаюсь, что там все настолько просто, что лишний вызов так заметен. Объясните мне, что, кроме строчек кода, сэкономит переход на вызовы SetPen.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>И все таки я возвращаюсь к своему исходному вопросу: почему вызов Create-Select-Destroy настолько дороже, чем SetPen()? Ну пусть он будет в три раза дороже — не жалко. Хотя я очень сомневаюсь, что там все настолько просто, что лишний вызов так заметен. Объясните мне, что, кроме строчек кода, сэкономит переход на вызовы SetPen.
Из C++ наверное действительно все равно. Практически. Я не знаю что стоит handle managment в недрах Windows но наверное не слишком дорого. Непонятно зачем но это действительно другой вопрос.
В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс
еще напрягать предмет Владовой гордости — HandleCollector.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Sinclair, Вы писали:
S>>И все таки я возвращаюсь к своему исходному вопросу: почему вызов Create-Select-Destroy настолько дороже, чем SetPen()? Ну пусть он будет в три раза дороже — не жалко. Хотя я очень сомневаюсь, что там все настолько просто, что лишний вызов так заметен. Объясните мне, что, кроме строчек кода, сэкономит переход на вызовы SetPen.
CS>Из C++ наверное действительно все равно. Практически.
Ок. То есть архитектура нормальная. Уже неплохо. CS> Я не знаю что стоит handle managment в недрах Windows но наверное не слишком дорого. Непонятно зачем но это действительно другой вопрос.
Хм, а вот другой гуру по соседству тут страдает от того, что карандаши дорого стоят, и ругает за это архитектуру. Вот я собственно его и спрашивал, почему он думает, что SetPen не станет занимать в сто раз больше времени чем LineTo. CS>В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс CS>еще напрягать предмет Владовой гордости — HandleCollector.
Ну и причем тут маршалы и пины? Мы вообще о чем говорим — об архитектуре, или о стоимости маршаллинга из управляемого кода в неуправляемый?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Точно так же потеря соеденения с БД из пула не является проблемой. Когда соеденения закончатся можно собрать мусор и получить все потери обратно.
а что — в .НЕТ повсеместно пулы соединений с БД нелимитированные? во сколько раз увеличится response time если на каждый запрос будет открыватся соединение после того как уже аллоцированные конекты будут исчерпаны? в MSSQL/TCP stack нет оверхеда на создания конекшна? и вообще resultset незакрытый блокировки оставляет. как раз потеря соединания из пула это одна из самых страшных ошибок, ИМХО.
Здравствуйте, VladD2, Вы писали:
VD>Что же касается слов ИТ, то он говорил о такой удобной вещи как using () и паттерне Dispose на котором он основан. Это в сто раз удобнее чем использование try/finally с ручным закрытием ресурсов. Вот тебе простой пример вот такой код:
короче — если лень писать try/finally самому — поручи это дело компилятору. вот например, проект, позволяющий макросы разворачивать в Java код. Java Syntax Extender
можно легко наворотить почти любых синтаксических конструкций.
Здравствуйте, Sinclair, Вы писали:
CS>>В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс CS>>еще напрягать предмет Владовой гордости — HandleCollector. S>Ну и причем тут маршалы и пины? Мы вообще о чем говорим — об архитектуре, или о стоимости маршаллинга из управляемого кода в неуправляемый?
Дело и в архитектуре тоже. Просто такая схема является потенциально дорогой, хотя в частных случаяъ может работать быстро. Это примерно то же самое, как если бы для каждой целочисленной переменной требовался бы отдельный системный HANDLE. Ну или что-то типа такого:
graphics.LineTo(new int(100), new int(100));
Причем это должно быть именно требованием — создавать переменные в куче, а еще лучше — ассоциировать их с отдельными HANDLE. Идет ли здесь речь об архитектуре или нет?
Точно так же, понятие "карандаша" — это абстракция, притянутая за уши. Цвет — это такое же фундаментальное понятие, как, например, int. И создавать карандаш для каждого цвета в отдельности — примерно то же самое, что создавать системный HANDLE для каждой переменной. То, что мы в Java можем написать "int i;" — это всего-лишь оптимизация. Но она имеет фундаментальное значение.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Это если где-нить внизу не попадется неуправляемый стековый фрэйм.
ANS>Хм. Интересный вопрос. Ситуация маловероятная, но всё же... Нужно уточнить.
Что же это маловерятная? Пока ОС неуправляемая, ситуация эта очень даже возможна.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>короче — если лень писать try/finally самому — поручи это дело компилятору. вот например, проект, позволяющий макросы разворачивать в Java код. Java Syntax Extender
Про этот проект я знаю. Но это эксперемент имеющий мало отношения к реальному программированию. А я бы хотел иметь такию фичу в реальном коде. Собственно оно описано в пункте 10 вот этого сообщения
. В Яве такая фича тоже не помешала бы. Но к сожалению это все не так просто. Ведь тут кроме модификации языка нужно еще приучать к этому делу отладчик, редактор, средства рефакторинга и т.п.
N>можно легко наворотить почти любых синтаксических конструкций.
Не легко, но согласен вещь мощьная. Навеяна макросами лиспа.
Однако пока что ее нет и лично ты долбишь try/finally своими ручками. И это не единственный паттернк который тебе придется долбить самому. Мни лично это делать не охота. Лучше уж иметь их встроенными в язык. Поэтому я предпочитаю Шарп.
Но если появится нечто промышленного качества поддерживающее расширение синтаксиса, то я с удовольствием буду писать на этом чуде.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
VD>>Точно так же потеря соеденения с БД из пула не является проблемой. Когда соеденения закончатся можно собрать мусор и получить все потери обратно.
N>а что — в .НЕТ повсеместно пулы соединений с БД нелимитированные? во сколько раз увеличится response time если на каждый запрос будет открыватся соединение после того как уже аллоцированные конекты будут исчерпаны? в MSSQL/TCP stack нет оверхеда на создания конекшна? и вообще resultset незакрытый блокировки оставляет. как раз потеря соединания из пула это одна из самых страшных ошибок, ИМХО.
Пул на то и нужен, чтобы время выделения ресурса стремилось к нулю.
Вот и в дотнете для соеденений он используется именно для этого. Лично я выделяю соеденения примерно так:
using (SqlConnection connection = new SqlConnection(connectionString))
{
// выполение запросов...
}
Но даже если этого не сделать, а просто забывать ссылки, то при нехватке соеденений будет собран мусор и они все снова вернутся в пул соеденений.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Ошибка ошибке рознь. Это была ошибка примерно такого же уровня, что и неинициализированный указатель в ядре OS. Если бы не было исправлено, на системе можно было бы ставить жирный крест. И один факт выхода в production подобного ляпа говорит очень о многом.
Мне кажется ты сильно приувеличивашь. Если бы не ты, то никто бы и не узнал об этом баге. Лично я вот не знал.
MS>До сих пор использую VC6, причем очень активно, как рабочую лошадь. Ни одного случая неверной кодогенерации не припомню. ICE — случаются.
Вот влидишь, ты способен пользоваться даже откровенно глючным компилятором. Что же тогда говорить о мнее прихотливых пользователях?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
ПК>Не уверен, насколько это работает, но многие рекламируют Safe Handles из .Net FW 2.0.
Можно проще — в конструкторе GC.AddMemoryPressure в деструкторе GC.RemoveMemoryPressure. Делают именно то, что нужно
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, McSeem2, Вы писали:
MS>Сначала делается обобщенная абстракция в виде карандашей и кистей. Абстракция является дорогим удовольствием, поэтому карандаши надо кэшировать (карандаши — одна нелепость, порождающая другую — кэширование). Это заместо простых и понятных SetLineColor()/SetFillColor(), которые как раз и нужны в 99% случаев (сплошной цвет, безо всяких там паттернов). Вот зачем на каждый цвет создавать отдельный карандаш? Лично я не вижу в этом ни малейшей рациональности. Троечники проектировали. Серые безнадежные троечники.
Думаю, мы никогда не прийдем к единому мнению, так как я говорю об удобстве работы с библиотекой программиста. А ты о каких-то мало понятном мне вреде абстракций.
Для меня абстракция — добро. Для тебя — зло.
Я не понимаю зачем мне нужен вообще какой-то SetXxx(). Я не хочу что-то ассоциировать с контекстом. Мне вообще не нужен контекст. Однако я не против методов вроде FillSolidRectagel() или Solidline() которые получали бы в качестве парамтра просто цвет. В общем, я устал говорить, что я за оптимальные решения. Но только не засчет уменьшения удобства использования библиотеки.
VD>>Не случится — значит и времени убито не будет. Пара ресурсов на фоне отрисовки будут просто незаметны.
MS>Создание/удаление одного карандаша — примерно как нарисовать сотню линий (по крайней мере было так пяток лет назад).
Не уверен, что это так на сегондя. Хотя по фигу. Еще раз. Ты не о том беспокошся.
MS> При этом каждый карандаш может понадобиться один единственный раз
А может сотню. И что?
MS>Математики стремятся сокращать все, что сокращается — это создает красоту и стройность.
Вот потому их не могут понять люди не привыкшие к спартанским условиям.
В общем, вы так и не ответили зачем нужно связываться со всеми этоим SetXxx()? Ведь скорости можно достчь и без них. А вот удобства с ними фиг добъешся.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Более того в GDI нет ни одной функции берущей на вход HPEN кроме SelectObject.
Забавный аргумент. А что есть что-то что берет другие примитивы? Они все в контекст сандалятся. Только это то и убого. Ну, не удобно работать с GDI. Неудобно пасти все хэндлы и сменять их по одному. Куда удобнее жить в ОО-мире. Задавать нужные объекты при отрисовке того-то или того-то. Потому люди делающие высокоуровневые библиотеки и пытаются уйти от подхода принятого в GDI. А вы тянете обрано в 20 век. Нафигнафиг.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс CS>еще напрягать предмет Владовой гордости — HandleCollector.
1. Где я чем-то гордился?
2. Нет никаких пинов. Хэндл — это вэлью-тип хранящий некое число ассоциированное с ресурсом. Так что тут никакого оверхэда.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Точно так же, понятие "карандаша" — это абстракция, притянутая за уши. Цвет — это такое же фундаментальное понятие, как, например, int. И создавать карандаш для каждого цвета в отдельности — примерно то же самое, что создавать системный HANDLE для каждой переменной. То, что мы в Java можем написать "int i;" — это всего-лишь оптимизация. Но она имеет фундаментальное значение.
Понимаш ли, мне плевать какой там карандаш. Он рисует не смотря на то является ли он монотонным или картинкой. Вот за тем он и нужен. И пусть библиотека думает, как там внутри оптимизировать все это дело.
Я вот вспоминаю первые книжки по ООП где в качестве примера давались иерархии классов графических приметивов. Там примитивы и получали точки. Брали точки и получали фигуры... В конеце получали все что угодно. Красиво... но не эффективно. Но ведь без проблем можно оставить ту же иерархию, но пользоваться некими более быстрыми средствами для отрисовки. Вот и тут тоже самое. Толко с точностью до наоборот. Нам указывают на неэффективность лобовой реализации и вместо того чтобы оставить интерфейс и изменить реализацию нам предлагается изменить интерфейс. При этом даже не объясняется с чего бы при этом что-то начнет работать лучше.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Понимаш ли, мне плевать какой там карандаш. Он рисует не смотря на то является ли он монотонным или картинкой.
Карандаш картинкой? Это явный гон. Никто такого не умеет делать, только я умею, да и то со значительными ограничениями. Нарисовать линию паттерном в виде произвольного битмапа, да еще и с фильтрацией — это не просто задача, это — мегазадача. Изобретение карандашей по сравнению с такой задачей — это детская песочница, не стоящая упоминания.
То есть, получается так, что для рисования таких сложных вещей карандаши — это мелочь. А вот для сплошных цветов они портят жизнь, точно так же, как портила бы жизнь необходимость каждую переменную создавать через new.
VD>Я вот вспоминаю первые книжки по ООП где в качестве примера давались иерархии классов графических приметивов. Там примитивы и получали точки. Брали точки и получали фигуры... В конеце получали все что угодно. Красиво... но не эффективно.
Тебя обманули, ООП заключается вовсе не в этом. Не спрашивай меня, в чем оно заключается, но могу сказать, что точно не в иерархиях классов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А кто в .Net вызывает деструктор?
А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс CS>>еще напрягать предмет Владовой гордости — HandleCollector.
VD>1. Где я чем-то гордился?
Где-то там "выше и левее".
Я так понял что ты собираешься еще и свой написать — что-то там про HashTable и handles мелькало.
VD>2. Нет никаких пинов. Хэндл — это вэлью-тип хранящий некое число ассоциированное с ресурсом. Так что тут никакого оверхэда.
Да, наверное это так. Но все равно HandleCollector наличествует.
Кстати странный зверь этот HandleCollector.
Как я понимаю это банальный reference counter.
Что называется и в борьбе с зеленым змием побеждает змий.
1.1.4 stable rev. 510
