Здравствуйте, VladD2, Вы писали:
VD>Разница между оптимизацией по Дворкину и оптимизацией джита заключается в том, что в одном случае он будет делать ее руками накосячив и сделав не то что нужно, а во втором случае это будет продуманная оптимизация джита. При этом она гарантированно не будет влиять на результаты вычисений.
Это вилами по воде писано. MS VC++, например, в релизе может генерировать совершенно левый код делающий просто не то. Эти случаи правда хорошо известны, но тем не менее. Так что способность MS делать стабильные низкоуровневые оптимизации не то что бы совсем под вопросом, но их продукты в этом смысле не идеальны.
VladD2 wrote: > > Pzz>Это если ему есть куда. В однопоточной программе места, куда ему расти, > Pzz>обычно хоть попой ешь. Но вот в многопоточной программе расти ему > Pzz>предстоит только до следующего стека (до стека другого потока). А дотуда > Pzz>может быть не так уж и далеко. > > А, кстати, что мешает в один прекрасный момент поглядеть, что стэка > мало... вставить некую процедуру-заглушку и создать новый стэк? Эта > заглушка будет первой функцией в новом стэке. Как только ей передадут > управление она востановит указатель стека на старый стек и все дела.
Видимо считается, что сложность превышает потребность.
Здравствуйте, adontz, Вы писали:
A>Это вилами по воде писано. MS VC++, например, в релизе может генерировать совершенно левый код делающий просто не то. Эти случаи правда хорошо известны, но тем не менее. Так что способность MS делать стабильные низкоуровневые оптимизации не то что бы совсем под вопросом, но их продукты в этом смысле не идеальны.
Есть лучше?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pzz, Вы писали:
>> А, кстати, что мешает в один прекрасный момент поглядеть, что стэка >> мало... вставить некую процедуру-заглушку и создать новый стэк? Эта >> заглушка будет первой функцией в новом стэке. Как только ей передадут >> управление она востановит указатель стека на старый стек и все дела.
Pzz>Видимо считается, что сложность превышает потребность.
Вчера вот почитал отчет о Сингулярити там как раз так и сделано. Управляемая среда позволяет статически анализировать поток управления и вычислять необходимый размер стэка. Далее дело техники. Стек становится много сегментрым, а ОС в некоторых случаях вставляет проверки. Правда в одном месте есть замечание, что мол было бы круто если бы это дело поддерживалось аппаратно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
VD>>Разница между оптимизацией по Дворкину и оптимизацией джита заключается в том, что в одном случае он будет делать ее руками накосячив и сделав не то что нужно, а во втором случае это будет продуманная оптимизация джита. При этом она гарантированно не будет влиять на результаты вычисений.
A>Это вилами по воде писано. MS VC++, например, в релизе может генерировать совершенно левый код делающий просто не то. Эти случаи правда хорошо известны, но тем не менее. Так что способность MS делать стабильные низкоуровневые оптимизации не то что бы совсем под вопросом, но их продукты в этом смысле не идеальны.
Ну, заеш ли. Если сделать логическую ошибку просто при генерации каой-нибудь ассемблерной инструкции, то можно вообще что угодно получить. Я все же веду речь о том, что эта оптимизация полностью кортролируема и основана на серьезных логических и мат. выкладках, а стло быть может быть реализована без вреда для окружающего кода.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Да все что угодно. Хочешь создавай, хочешь нет. CS>В 99% приложений таблица фонтов вообще полу-статическая.
Так у тебя на сегодня как все устроено? Есть кэш?
CS>Создаются динамически но освобождаются вместе с завершением процесса.
Э... представь себе комбик в Ворде где выводится список шрифтов из системы. Каждый шрифт отрисовывается самим сабой. Стало быть после просмотра этого комба мы получим кэш содержащий все шрифты. А это удовольствие не из дешевых.
Тут нужно или делать как я, кэшируя шрифт только на время отрисовки, или создавать сложный кэш кэширующий определенное количество шрифтов и удерживающий в живых те кторые наиболее часто используюся (на базе подсчета рейтига).
CS>Еще раз. Сделай сам себе объекты-описатели с нужным тебе набором свойств если тебе надо.
Так и сделал. Что и предлагаю.
CS>Только свой собственный и сугубо managed сиречь работающий в режиме fire-n-forget.
А зачем "forget"? Храни их хоть до посинения если они нужны в программе.
VD>>В общем, еще раз... Чем тебе не угадили объекты?
CS>Да мне лично они до лампочки. Я framework не использую в т.ч. по причинам изложенным — плохо спроектирован.
Ясно. Но что-то мне твои предложения нравятся еще меньше чем те что во фрэймворе.
CS>Я (и мы все здесь) пытаюсь понять в чем беда Java и .NET GUI?
Уж точно не из-за того что они спроектрованы в ОО-манере.
CS>Концепт "все в managed" в реальности выливается в то что на самом деле CS>unmanaged хэндлами засеян весь фреймворк квадратно гнездовым образом.
Во-первых, ты несколько сгущаешь краски. Во-вторых, при правильности потановки вопроса ты предлагашь весма странное решение проблемы. Мне кажется тут все же нужно говорить не об избавлении от объектов, а об избавлении от ручного управления теми самыми хэндлами.
CS>Такое впечатление что: CS>Проектировщики WinForms либо допустили банальную архитектурную ошибку — еще раз встали на те же грабли что и Java.
В самом WinForms проблем с хэндлами нет. Проблему можно углядеть в GDI+, но в отместку в WinForms создана целая иделогия слежения за хэндлами. Так что не все так страшно. А то там за проблемы в Яве я компетентно говорить не могу.
CS>Либо изначально это все и не было раcчитано на эффективную работу.
И все же ты путашь эффективность и грамотность проектирования. Эффективность зависит не от политики слежения за хэндлами. Она зависит от общего дизайна библиотеки. Вот SWING и GDI+ спроектированы не лучшим образом с точки зрения производительности.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
A>>Это вилами по воде писано. MS VC++, например, в релизе может генерировать совершенно левый код делающий просто не то. Эти случаи правда хорошо известны, но тем не менее. Так что способность MS делать стабильные низкоуровневые оптимизации не то что бы совсем под вопросом, но их продукты в этом смысле не идеальны. WH>Есть лучше?
А с другой стороны, не ты ли нашёл глюк, когда три вызова rand() в релизе заменялись одним?
Так что я оптимизма категории "всех шапками закидаем" не разделяю и ожидать такой интеллектуальности в ближайшие 5 лет ИМХО наивно.
Здравствуйте, VladD2, Вы писали:
VD>Ну, заеш ли. Если сделать логическую ошибку просто при генерации каой-нибудь ассемблерной инструкции, то можно вообще что угодно получить. Я все же веду речь о том, что эта оптимизация полностью кортролируема и основана на серьезных логических и мат. выкладках, а стло быть может быть реализована без вреда для окружающего кода.
Здравствуйте, VladD2, Вы писали:
VD>Вот расскажи об этом c-smile, а то он утверждает, что кисти и карандаши очень дешевы. Видимо вы их в разных количествах используете.
В его реализации они действительно дешевы, ибо не связаны с системными ресурсами. Но все равно я не вижу ни малейшего смысла в этих карандашах — только лишнее нагромождение.
MS>> Это яркий пример "обобщенной абстракции", за которую следует немедленно отвинчивать яйца с особым цинизмом — ламеры интерфейс дизайнили. Но дело не в этом. Для GC это конечно же не цифры, но сами объекты жутко дороги по времени, а GC об этом не знает и знать не может.
VD>Ты точно мое сообщение до конца дочитал? Позволю себе процетировать себя: VD>
Я вот опробовал другую идею. В Graphics кэшируются реальные ресурсы выделяемые ОС. А все объекты вроде Font, Brash и т.п. только хранят их описание. Внутри Graphics имеются банальные хэш-таблицы ассоциирующие эти объекты с хэндлами ОС. ...
Во-во. Это была подстава — я к этому и подводил. Теперь вопрос — а нафига нужны такие сложности в виде решения задачи методом чайника (вылить из чайника воду и свести задачу к предыдущей)?!
Ведь хеш поможет только в случае повторного использования объектов, которого может и вовсе не случиться. Получается нагромождение одной нелепости на другую.
VD>То же не спорю. В общем, не могу понять споришь ты со мной или соглашаешся.
А почему ты это спрашиваешь?
На самом деле я просто зацепился за твое утверждение и пытаюсь внести ясность, что дело не только в GC.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Да все что угодно. Хочешь создавай, хочешь нет. CS>>В 99% приложений таблица фонтов вообще полу-статическая.
VD>Так у тебя на сегодня как все устроено? Есть кэш?
Для шрифтов — конечно. По другому я собсвенно и не знаю как.
CS>>Создаются динамически но освобождаются вместе с завершением процесса.
VD>Э... представь себе комбик в Ворде где выводится список шрифтов из системы. Каждый шрифт отрисовывается самим сабой. Стало быть после просмотра этого комба мы получим кэш содержащий все шрифты. А это удовольствие не из дешевых.
VD>Тут нужно или делать как я, кэшируя шрифт только на время отрисовки, или создавать сложный кэш кэширующий определенное количество шрифтов и удерживающий в живых те кторые наиболее часто используюся (на базе подсчета рейтига).
Давай сделай следующее:
Открой Windows Task Manager в нем покажи столбец GDI resources
Открой Word. Посмотри количество GDI handles.
Теперь открой в нем combobox Fonts. Пролистай его содержимое до конца
(это обязательно, В Word таблица шрифтов полустатическая).
Посмотри опять количество GDI handles. Оно должно увеличиться примерно
на количесво тем в этом комбобокс.
Закрой комбобокс.
Посмотри опять количество GDI handles.
Здравствуйте, VladD2, Вы писали:
VD>И ничего хорошего.
Давай уточним, что ты имеешь в виду под "попиксельным рисованием". Конкретно вызов функции WinAPI SetPixel() или что-то другое? И если что-то другое, то что конкретно?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>2. Ты сам-то пробовал код по этой ссылке тестировать? У меня пустой экран получается.
Дык! Вообще-то я этот код и написал. Если бы и сейчас получался непустой экран, это было бы вообще кисло. Исправлено в FW1.1.
Что же касается "логически доказуемой оптимизации", то при превышении некого предела сложности (который в дот-нет уже превышен), эта "оптимизация" становится недоказуемой на практике. Теоретически, можно строго математически доказать или опровергнуть корректность любой программы. На практике, время такого докеазательства может превысить время жизни Вселенной. Получается как в Oracle — наворотили жутко оптимизирующий исполнитель запросов, после чего появилась профессия "оптимизатора" — надо уметь дать оптимизатору такие подсказки (хинты), чтобы он не умничал, а сработал просто и быстро. Подозреваю, что нечто подобное будет и для Java, C# и прочих (специальные хинты оптимизатору).
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, VladD2, Вы писали:
VD>>Вот расскажи об этом c-smile, а то он утверждает, что кисти и карандаши очень дешевы. Видимо вы их в разных количествах используете.
MS>В его реализации они действительно дешевы, ибо не связаны с системными ресурсами. Но все равно я не вижу ни малейшего смысла в этих карандашах — только лишнее нагромождение.
VD>>Ты точно мое сообщение до конца дочитал? Позволю себе процетировать себя: VD>>
Я вот опробовал другую идею. В Graphics кэшируются реальные ресурсы выделяемые ОС. А все объекты вроде Font, Brash и т.п. только хранят их описание. Внутри Graphics имеются банальные хэш-таблицы ассоциирующие эти объекты с хэндлами ОС. ...
MS>Во-во. Это была подстава — я к этому и подводил.
Где подстава? О чем ты? За нами следят?
MS> Теперь вопрос — а нафига нужны такие сложности в виде решения задачи методом чайника (вылить из чайника воду и свести задачу к предыдущей)?!
Какие тебе чайники мерещатся?
MS>Ведь хеш поможет только в случае повторного использования объектов, которого может и вовсе не случиться. Получается нагромождение одной нелепости на другую.
Не случится — значит и времени убито не будет. Пара ресурсов на фоне отрисовки будут просто незаметны.
VD>>То же не спорю. В общем, не могу понять споришь ты со мной или соглашаешся.
MS>А почему ты это спрашиваешь?
А почему ты отвечашь?
MS>На самом деле я просто зацепился за твое утверждение и пытаюсь внести ясность, что дело не только в GC.
Я как бы утверждал, что дело вообще не в ЖЦ, как это хотел представить автор темы. Бессмысленно говорить о "(макро|макро)менеджмента памяти" когда дело в управлении ресурсами ОС вроде шрифтов и кистей.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Дык! Вообще-то я этот код и написал. Если бы и сейчас получался непустой экран, это было бы вообще кисло. Исправлено в FW1.1.
Ну, то есть, исправили ошибку и живут дальше? То есть, все ОК?
MS>Что же касается "логически доказуемой оптимизации", то при превышении некого предела сложности (который в дот-нет уже превышен), эта "оптимизация" становится недоказуемой на практике.
Месье верит в практику и не верит в математику и логику?
MS> Теоретически, можно строго математически доказать или опровергнуть корректность любой программы.
Не. Любой нельзя. Вот, например, любая программа на С++ в которой используются нетипобезопасные механизмы (а это почти любая программа на С++ которая больше Х строк) принципиально не может содержать доказуемо морректна, так как в ней море UB.
MS> На практике, время такого докеазательства может превысить время жизни Вселенной.
Это софистика. Если говорить о размещении объектов в стеке, то доказать нужно только то что ссылка на объект не уйдет "налево". В рамках типобезопасного языка это вполне решаемая задача. Делаем флоу-анализ и смотрим не пытается ли код засунуть ссылку на объект в другой объект, переменную, рефлекшон и т.п. Если пытается, то отказываемся от оптимизации. Если нет, размещаем объект в стеке. Так как все в управляемом коде описано нет проблем сделать такое преобразование. Вот в С++ это будет уже сложнее, так как в любой момент может оказаться так, что программист вычислил адрес объекта вручную.
MS> Получается как в Oracle — наворотили жутко оптимизирующий исполнитель запросов, после чего появилась профессия "оптимизатора" — надо уметь дать оптимизатору такие подсказки (хинты), чтобы он не умничал, а сработал просто и быстро.
Кстати, не надо валить напраслину на оптимизатор Оракла. Он не гениален, но очень даже умен. И хинты ему в 99% случав не нужны. И хинты влияют исключительно на скорость выполнения запросов, но ни как не на их результат.
MS> Подозреваю, что нечто подобное будет и для Java, C# и прочих (специальные хинты оптимизатору).
Я думаю, что будет только один тип хинтов — отказаться от оптимизации. Собственно такое уже есть. Есть атрибут запрещающий автоинлайнинг метода. На практике его применение я видел только в тестах. Думаю, что если оный появится в реальной программе, то это будет первым признаком того, что надо что-то менять в команде разработки.
ЗЫ
Я видел людей боящихся включить оптимизацию в С++-компиляторе. И в общем-то понимаю их мотивы. Оптимизаторы компиляторов вроде VC (особенно во времена 6 и раньше) часто превышали свои полномочия или в сочетании с проблемами языка давали потрясающие эффектны. (Лирическое отсупление. В неоптимизированном виде С++-ный код работает как минимум не быстрее дотнетного, так что в чем приемущество его применения я уже вообще не понимаю.)
Но в управляемых средах все не так грусно. И оптимизации по взвещенее делаются, и контроля по больше, и предмета для оптимизаций по больше, и необходимость по выше, и, что наверно самое важное, нет того самого не безопасного кода который в сочетании с колдовством компилятора может породить удивительные глюки. Так что, думаю, в ближайшие несколко лет это направление будет серьезно развиваться. Не даром МС дает деньги на Феникс и Барток.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Давай уточним, что ты имеешь в виду под "попиксельным рисованием". Конкретно вызов функции WinAPI SetPixel() или что-то другое? И если что-то другое, то что конкретно?
Я лично работал только с SetPixel (или как там его) и еще ручной модификацией битмапа. В последнем случае откровенно задолбался с индексированными цветами. Первый тормозил не под детский. А главное, что необходимость делать (лично мне) подобные низкоуровневые опрерации в общем-то равна нулю.
Лично ты, насколько мне известно, как раз занимаешся софтовой работой с графикой на низком уровне. Тебе может этот способ и подойдет. Но нам с ИТ рисование пикселей может понадобиться тольк разве что в каком-нибудь движке отчетов. А там такой низкий уровень явно избыточен.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Для шрифтов — конечно. По другому я собсвенно и не знаю как.
Ну, вот орлы из МС во второй фрэймворк добавили класс System.Windows.Forms.TextRenderer с целью упростить пользовательскую отрисовку в контролах вроде ListView/TreeView. Так они там по простому создают шрифты перед использованием и уничтожают после. Работает это дело медленее чем даже GDI+, но на современных компьютерах терпимо.
А по моим эксперементам ширфты можно кэшировать толко на время отрисовки (если контрол большой), так как создание 2-10 шрифтов практически не заметно на фоне отрисовки.
CS>Давай сделай следующее:
CS>Открой Windows Task Manager в нем покажи столбец GDI resources CS>Открой Word. Посмотри количество GDI handles. CS>Теперь открой в нем combobox Fonts. Пролистай его содержимое до конца CS>(это обязательно, В Word таблица шрифтов полустатическая). CS>Посмотри опять количество GDI handles. Оно должно увеличиться примерно CS>на количесво тем в этом комбобокс. CS>Закрой комбобокс. CS>Посмотри опять количество GDI handles.
CS>Выводы?
Хм... Забавно. Действительно эти уроды кэшируют GDI-объекты. Причем когда выбирашь один из шрифтов в документе, то добавляется еще один GDI-объект, а старые не освобождаются. Однако они все же освобождаются при закрытии документа. То есть кэш делается на документ плюс комб делает отдельный кэш. Память при этом в общем-то почти не расходуется (на 300 кил. можно глаза закрыть).
Ну, что же я могу сказать. Ворд действительно в наглую кэширует все шрифты. При этом забавно выглядит освобождение кэша при закрытии документа, так как в комбе за раз у меня кэшируется более 150 хэндлов.
Но какие выводы отсюда можно сделать? Есть ли смысл говорить об экономии управляемых объектов если при этом может висеть по нескольку сотен системных?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
MS>> Теперь вопрос — а нафига нужны такие сложности в виде решения задачи методом чайника (вылить из чайника воду и свести задачу к предыдущей)?!
VD>Какие тебе чайники мерещатся?
Сначала делается обобщенная абстракция в виде карандашей и кистей. Абстракция является дорогим удовольствием, поэтому карандаши надо кэшировать (карандаши — одна нелепость, порождающая другую — кэширование). Это заместо простых и понятных SetLineColor()/SetFillColor(), которые как раз и нужны в 99% случаев (сплошной цвет, безо всяких там паттернов). Вот зачем на каждый цвет создавать отдельный карандаш? Лично я не вижу в этом ни малейшей рациональности. Троечники проектировали. Серые безнадежные троечники.
VD>Не случится — значит и времени убито не будет. Пара ресурсов на фоне отрисовки будут просто незаметны.
Создание/удаление одного карандаша — примерно как нарисовать сотню линий (по крайней мере было так пяток лет назад). При этом каждый карандаш может понадобиться один единственный раз — в этом случае кэширование нужно как утром по весне прошлогодний снег. А производительность системы определяется самым медленным компонентом.
Математики стремятся сокращать все, что сокращается — это создает красоту и стройность.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Ну, то есть, исправили ошибку и живут дальше? То есть, все ОК?
Ошибка ошибке рознь. Это была ошибка примерно такого же уровня, что и неинициализированный указатель в ядре OS. Если бы не было исправлено, на системе можно было бы ставить жирный крест. И один факт выхода в production подобного ляпа говорит очень о многом.
VD>Я видел людей боящихся включить оптимизацию в С++-компиляторе. И в общем-то понимаю их мотивы. Оптимизаторы компиляторов вроде VC (особенно во времена 6 и раньше) часто превышали свои полномочия или в сочетании с проблемами языка давали потрясающие эффектны. (Лирическое отсупление. В неоптимизированном виде С++-ный код работает как минимум не быстрее дотнетного, так что в чем приемущество его применения я уже вообще не понимаю.)
До сих пор использую VC6, причем очень активно, как рабочую лошадь. Ни одного случая неверной кодогенерации не припомню. ICE — случаются.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, VladD2, Вы писали:
MS>>> Теперь вопрос — а нафига нужны такие сложности в виде решения задачи методом чайника (вылить из чайника воду и свести задачу к предыдущей)?!
VD>>Какие тебе чайники мерещатся?
MS>Сначала делается обобщенная абстракция в виде карандашей и кистей. Абстракция является дорогим удовольствием, поэтому карандаши надо кэшировать (карандаши — одна нелепость, порождающая другую — кэширование). Это заместо простых и понятных SetLineColor()/SetFillColor(), которые как раз и нужны в 99% случаев (сплошной цвет, безо всяких там паттернов). Вот зачем на каждый цвет создавать отдельный карандаш? Лично я не вижу в этом ни малейшей рациональности. Троечники проектировали. Серые безнадежные троечники.
VD>>Не случится — значит и времени убито не будет. Пара ресурсов на фоне отрисовки будут просто незаметны.
MS>Создание/удаление одного карандаша — примерно как нарисовать сотню линий (по крайней мере было так пяток лет назад). При этом каждый карандаш может понадобиться один единственный раз — в этом случае кэширование нужно как утром по весне прошлогодний снег. А производительность системы определяется самым медленным компонентом. MS>Математики стремятся сокращать все, что сокращается — это создает красоту и стройность.
Я так понимаю, что ты ожидаешь от SetLineColor/SetFillColor пулеметной скорострельности, по сравнению с CreatePen/SelectPen. Так? Это нигде не прозвучало в явном виде, но судя по наездам на создание карандашей ты считаешь именно так.
А теперь я хочу спросить — а почему, собственно, ты так думаешь? Я вот не могу понять, почему операция CreatePen+SelectPen должна быть намного дороже чем SetLineColor. В случае однотонного карандаша, естественно. В чем такая уж существенная разница? Благодаря какой магии мы экономим внутрях SetLineColor? Пока что я вижу два вызова вместо одного. Хм, может, оно будет чуть-чуть дороже. Но на том же уровне наивности поочередное рисование двумя сложными карандашами будет быстрее в случае отдельного создания. Потому что по логике SetLinePattern() делает то же самое, что и CreatePatternPen()+SelectPen(), но каждый раз. А CreatePatternPen() мы можем вынести за пределы цикла.
Так что я прошу опытного в графике человека объяснить мне, где зарыта причина сверхъестественной медленности операций с объектами.
Потому как есть у меня подозрение, что дело вовсе не в архитектуре. А в том, что реализацию СreatePen() делали троечники, которым ее доверили в надежде на редкость вызова по сравнению с LineTo().
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
MS>>Создание/удаление одного карандаша — примерно как нарисовать сотню линий (по крайней мере было так пяток лет назад). При этом каждый карандаш может понадобиться один единственный раз — в этом случае кэширование нужно как утром по весне прошлогодний снег. А производительность системы определяется самым медленным компонентом. MS>>Математики стремятся сокращать все, что сокращается — это создает красоту и стройность. S>Я так понимаю, что ты ожидаешь от SetLineColor/SetFillColor пулеметной скорострельности, по сравнению с CreatePen/SelectPen. Так? Это нигде не прозвучало в явном виде, но судя по наездам на создание карандашей ты считаешь именно так.
S>А теперь я хочу спросить — а почему, собственно, ты так думаешь? Я вот не могу понять, почему операция CreatePen+SelectPen должна быть намного дороже чем SetLineColor. В случае однотонного карандаша, естественно. В чем такая уж существенная разница? Благодаря какой магии мы экономим внутрях SetLineColor? Пока что я вижу два вызова вместо одного. Хм, может, оно будет чуть-чуть дороже. Но на том же уровне наивности поочередное рисование двумя сложными карандашами будет быстрее в случае отдельного создания. Потому что по логике SetLinePattern() делает то же самое, что и CreatePatternPen()+SelectPen(), но каждый раз. А CreatePatternPen() мы можем вынести за пределы цикла.
CreatePen аллоцирует нечто ассоциированное с handle в таблице . Но если посмотреть внимательно
то ни один тип Pen в GDI не требует ничего особо военного — того что можно
было бы экономить при создании.
LOGPEN проста как двери и имплемнтация SetPen(Style, Width, Color) тривиальна — установка текущих
регистров типа линии.
Более того в GDI нет ни одной функции берущей на вход HPEN кроме SelectObject.
Вопрос: зачем надо сначала создавать pen, потом его select, а потом destroy?
В чем сермяжность?
1.1.4 stable rev. 510
