Постулат №1:
GC это хорошо и malloc/free тоже хорошо.
В поисках идеала (для UI programing) пришел к следующему выводу:
GC как средство макроменеджмента памяти это то что нужно.
GC как средство микроменеджмента памяти это дрова.
Микроменеджмент памяти это прерогатива malloc/free и stack allocation.
Что есть macro и micro management? Поясню на примере:
Классический () подход современных Java или WinForms.net:
Скажем для того чтобы залить прямоугольгик каким-нибудь цветом мы имеем:
class Brush { Color color; ... }
class Graphics
{
void fillRect( Rect r );
}
Brush b = new Brush( new Color(0xFF,0,0) );
Rect r = new Rect( 10,10,100, 100 );
gfx.setBrush(b);
gfx.fillRect(r);
В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их. Как следствие система жутко не эффективная. Как правило Brush это обертка над системным HBRUSH в конце концов. Т.е. к тому же имеем еще и dispose со всеми вытекающими.
Brush как отдельный объект никому не нужен. Как правило все что с ним делается это вызывается конструктор и все.
Rectangle в общем-то тоже как самостоятельный объект представляет мало ценности. Тогда зачем они? (см. далее про j-smile)
Постулат №2:
Если некая GC система (runtime например) требует интенсивного explicit dispose это
означает ошибку в дизайне этой самой системы/runtime.
Код требующий dispose нужно выносить на уровень микроменеджмента.
Что я попытался сделать в j-smile (микро/макро был одной из основных идей дизайна):
тот же фрагмент кода выглядит так:
// class Brush { Color color; ... } - просто нет этого как сущности
// Color тоже нет. Вернее есть, но не как объект, а namespace для стат. функций. class Graphics
{
void fillRect( int x, int y, int w, int h );
}
gfx.setBrush(Color.RGB(0xFF,0,0));
gfx.fillRect(10,10,100, 100);
Менеджмент HBRUSH и всего такого (микроменеджмент) выполняет
С имплементация класса Graphics. Заведомо максимально эффективным образом.
Java же управляет макро объектами Windget, Widgets (container) и т.д.
Все вместе а) значительно снижает нагрузку на GC (мало объектов — мало мусора)
b) значительно снижает требования к самой VM Java — все интенсивные
вычисления делаются на стороне C.
Если посомтреть то j-smile-demo.exe
(самописная VM + copying GC) тактильно работает в общем-то c той же скоростью что
и Harmonia примеры ( D c крутым codegen ). И объем exe в общем-то идентичен.
j-smile-demo.exe это двоичный bundle: 200k(VM+runtime) + 200k bytecodes (noncompressed .class files)
Откомпилированные D самплы по размеру бинарников соизмеримы.
Постулат №3
Оптимальная система оптимально использует разные
механизмы memory managment.
"Все — managed" это имхо грубейшая ошибка дизайна которая например убила Java UI на корню.
.NET UI (WinForms) слепо содрав подход AWT/SWT успешно двигается в
том же самом направлении.
Вот такие вот мои мысли в слух если они кому интересны.
vitaly_spb,
> N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны? > > Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?
Что характерно, зачастую -- задолго до.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Rect в .NET — это value type. Соответственно GC тут не при чём. Проблема с Brush только одна — его нужно диспозить. Занимаемая ею память на эффективность программы никак не повлияет. Ну запустится GC не три раза за время работы программы, а четыре
Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Sinclair, Вы писали:
S>Все равно точнее. Если мы признаемся себе, что точки нам нужны во всех итерациях, то можно вынести их за цикл:
Ну это уже изменение области видимости. А вдруг в объемлющем блоке другой p описан ?
S>Я вот не уверен, что надо начинать рассуждения с add esp и прочих туманных деталей.
Для обучения — сразу не надо. Но все же программист на С++ должен понимать. что там ниже делается. Более того, ИМХО это вообще верно — чтобы качественно программировать на уровне N, надо понимать, что делается на уровне N-1. Уметь самому программировать на уровне N-1 не обязательно.
Здравствуйте, vitaly_spb, Вы писали:
IT>>Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?
_>да вот мне тоже кажется, что GC за себя всегда постоять сможет. Разберется он когда кому память выделять и без помощи программистов, думающих что их объекты самые тяжелые на свете
При этом анализатор агрегата будет анализировать, думатель... — у ей внутре ведь есть, кажется, думатель? — ...думатель будет думать, и таким образом агрегат станет у вас обучаться. Вы и ахнуть не успеете, как он у вас начнет сам печатать
Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".
Ты, Влад, похоже вообще не понимаешь о чем речь. Поясняю еще раз. Этот "битмаповый карандаш" — это как раз тот самый объектно-ориентированный фуфел, который нафиг никому не нужен в реальности — это чисто обманка. В всяком случае, я не видел ни одного человека, которому хоть раз бы понабодилось нарисовать произвольную линию таким образом.
Нужно вот что:
А теперь сопоставь результат с фалами 1...9.bmp
Во это то, что реально нужно и то, что микрософту слабо.
VD>Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.
Дизайн моей библиотеки выполнен в соответствии с классическими объектно-ориентированными канонами. И тем не менее, никаких иерархий классов там нет. Не нужны они.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, IT, Вы писали:
IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.
во-первых само наличие финалайзера это кривые руки программера, таких классов очень мало (по крайней мере в Жабе, думаю 1/10000), и для них просто оптимизация запрещена.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А кто в .Net вызывает деструктор?
А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Pzz, Вы писали:
>> А, кстати, что мешает в один прекрасный момент поглядеть, что стэка >> мало... вставить некую процедуру-заглушку и создать новый стэк? Эта >> заглушка будет первой функцией в новом стэке. Как только ей передадут >> управление она востановит указатель стека на старый стек и все дела.
Pzz>Видимо считается, что сложность превышает потребность.
Вчера вот почитал отчет о Сингулярити там как раз так и сделано. Управляемая среда позволяет статически анализировать поток управления и вычислять необходимый размер стэка. Далее дело техники. Стек становится много сегментрым, а ОС в некоторых случаях вставляет проверки. Правда в одном месте есть замечание, что мол было бы круто если бы это дело поддерживалось аппаратно.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> > Вопрос терминологический, но по-моему, здесь не происходит повторного вызова конструктора > Конструктор чего вызывается повторно? Ведь объект, на который указывает c не существует после вызова соответствующего деструктора
В таком случае в данном примере и в первый раз конструкторы "не вызывались": до исполнения конструктора объект не существует.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Есть объекты с детерминирванным временем жизни. CS>>Детерменированность как информация это то качество которое мы теряем при отданнии их на откуп GC.
IT>Не могу согласиться с этим утверждением. Время жизни объектов в системах с GC вполне детерминировано и определяется наличием живых ссылок на этот объект.
Это не та детерминированность. Для большой группы объектов в UI время жизни
известно заранее, это например все случаи RAII:
window::draw()
{
graphics gx(this);
....
рисуем
....
забываем что было такое gx.
}
graphics это не GC объект, а явно стековый.
Вторая группа объектов это те про которые GC и знать не надо.
Например:
class Graphics {
native void setFont(String name, int size, boolean bold, boolean italic)
}
внутри таблица шрифтов это например статическая хеш таблица.
Эта самая таблица не нужна GC ни в каком виде, а наоборот — только мешает.
Немного вне темы:
Java и его JNI мне представляется более разумной моделью изоляции GC/не-GC
чем MC++. MC++ это вообще каша какая-то с непонятным назначением и неясной моделью vm.
JNI прост как двери, естественен и никакого насилия над личностью — котлеты — отдельно,
инсекты — отдельно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, c-smile, Вы писали:
CS>>Вот такие вот мои мысли в слух если они кому интересны.
PD>Мысли интересны, но не кажется ли тебе, что это можно выразить короче ? А именно — для достаточно часто выполняемых коротких операций не надо дергать кучу , если это возможно и не противоречит высшим идеям При этом неважно, управляемая она или нет. Твой пример можно вполне на неуправляемый С++ перевести, и он там будет так же точно выглядеть, только явный вызов delete добавится. И эффекты будут те же — по скорости.
Вопрос на самом деле лежит в несколько иной плоскости:
Скажем грамотное (или оптимальное) использование memory managers.
Есть ситуации когда микроменеджмент выполняется в том числе с помощью new/delete (malloc/free) и само собой аллокацией на стеке. микроменеджмент памяти это ситуация когда мы знаем точно время жизни объекта.
Не использовать это знание — значит обрекать себя на неоптимальное решение.
И есть ситуации когда GC на высоте — заведомо лучше справляется с ситуацией или позволяет строить более надежную систему.
Имея опыт написания managed/unmanaged компонент на .NET(MC++) и Java(JNI) пришел к заключению
что модель native методов в Java (JNI) лучше. Во многих смыслах.
Macromangement памяти это удел таких систем как Java.
И это хорошо на самом деле что в ней нет всяких подпорок типа using.
Они там не нужны по большому счету.
RAII в С++ — он для этого то что надо. GC в Java — то что нужно.
Это я пытаюсь мыслить в слух в том числе на тему:
Все-в-одном как MC++ например это хорошо или плохо?
Что-то мне говорит что будет как всегда.
Здравствуйте, c-smile, Вы писали:
CS>В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их.
Rect в .NET — это value type. Соответственно GC тут не при чём. Проблема с Brush только одна — его нужно диспозить. Занимаемая ею память на эффективность программы никак не повлияет. Ну запустится GC не три раза за время работы программы, а четыре
Если нам не помогут, то мы тоже никого не пощадим.
CS>Постулат №3 CS>Оптимальная система оптимально использует разные CS>механизмы memory managment. CS>"Все — managed" это имхо грубейшая ошибка дизайна которая например убила Java UI на корню. CS>.NET UI (WinForms) слепо содрав подход AWT/SWT успешно двигается в CS>том же самом направлении.
У O'Camla тут интересное решение в виде двух куч — малой, для короткоживущих объектов. И большой — понятно для чего.
+ Естественно, все достаточно маленькие значения он кладет туда, куда нужно сразу.
Каким-то образом это пересекается с идеей регионов у cyclone — там нечто вроде стека из куч
Еще очень интересное направление — это region inference, когда копилятор статически определяет все точки на стеке, где есть ссылка на объект и освобождает память там, где объект выходит за пределы видимости.
Я боюсь, что просто разделения managed-unmanaged в 2005 году уже недостаточно — детали, все решают детали
Здравствуйте, n0name2, Вы писали:
N>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, n0name2, Вы писали:
N>>>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
IT>>>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
N>>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями...
IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.
В окамле это давно работает
Посколько внутри камл-программы мы вообще не видим никакого стека, ни регистров ничего такого, то компилятор этим нагло пользуется и раскидывает данные так, как ему удобно
за 15 лет ничего не сломалось :)
да не только окамл, большинство ML-компиляторов, Clean и Haskell так делают
теперь вот до Жабы на третьи сутки дошло :)
Здравствуйте, IT, Вы писали:
IT>В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.
даже если бы это было полностью верно, никто не гарантирует что, скажем, незакрытый File подберется в течении ближайших суток (если он вдруг успел запромоутится в permanent generation). ЖЦ это только средство управления памятью а не системными ресурсами. не надо его юзать для того, для чего он не предназначен изначально.
>> Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?
ПК>Что характерно, зачастую -- задолго до.
если это сервер, то поняимя "закрыть приложение" не существует — он практически всегда расчитан на то что он работает месяцами без остановки (хотя, конечно, под виндой если недельку продержится и то хорошо
при закрытии программы OS сама закроет все сокеты, файлы и т.д. и т.п., освободит всю память даже если ее не подобрал ЖЦ и т.д. без всяких финалайзеров.
try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов. MS фактически поощряет очень опасный стиль программирования. лучше 100 goto чем 1 финалайзер. и всякие хинты для ЖЦ это тоже самое что проверка в компиляторе — если ли коментарий перед goto объясняющий зачем он тут стоит и почему нельзя сделать цикл.
Здравствуйте, n0name2, Вы писали:
N>если это сервер, то поняимя "закрыть приложение" не существует — он практически всегда расчитан на то что он работает месяцами без остановки (хотя, конечно, под виндой если недельку продержится и то хорошо
Такое ощущение, что у тебя в своё время не сложилась любовь с виндой. Типа кто-то из вас кому-то не дала
N>при закрытии программы OS сама закроет все сокеты, файлы и т.д. и т.п., освободит всю память даже если ее не подобрал ЖЦ и т.д. без всяких финалайзеров.
Системные ресурсы да, а всяческие доморощенные?
N>try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов.
Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
WH>>Только тут надо иметь в виду что стек не резиновый... GZ>Ага, и то что запросить информацию об объекте и выполнить действия могут через внешний интерфейс типа reflection.
. Они не каждый объект на стэк будут помещать. Это будет делаться только если на объект нет никаких других ссылок. Там применяется мудреный анализ и при первом же подазрении на вшивость бубику в конуре отказывают.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>>>try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов. IT>>Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.
N>да ну? и чемже? отсутствием checked exceptions?
Забавно, что ты вошел в разговор на волне борьбы с одним предрассудком и тот час же начал насаждать другие.
Разговор о пользе/вреде checked exceptions наверно стоит перенести в отдельную ветку. Тут они ни причем.
Что же касается слов ИТ, то он говорил о такой удобной вещи как using () и паттерне Dispose на котором он основан. Это в сто раз удобнее чем использование try/finally с ручным закрытием ресурсов. Вот тебе простой пример вот такой код:
using System;
using System.IO;
class Program
{
static void Main()
{
string sourcePath = @"C:\boot.ini";
string destPath = Path.ChangeExtension(sourcePath, ".test");
string line;
using (StreamReader reader = File.OpenText(sourcePath))
using (StreamWriter writer = new StreamWriter(destPath))
while ((line = reader.ReadLine()) != null)
if (line.Contains("=\""))
writer.WriteLine(line);
}
}
если бы небало using-а пришлось бы записывать вот таким безобразным образом:
using System;
using System.IO;
class Program
{
static void Main()
{
string sourcePath = @"C:\boot.ini";
string destPath = Path.ChangeExtension(sourcePath, ".test");
string line;
StreamReader reader = null;
StreamWriter writer = null;
try
{
reader = File.OpenText(sourcePath);
writer = new StreamWriter(destPath);
while ((line = reader.ReadLine()) != null)
if (line.Contains("=\""))
writer.WriteLine(line);
}
finally
{
if (reader != null)
reader.Close();
if (writer != null)
writer.Close();
}
}
}
То есть, большая часть кода превращается в синтаксический оверхэд. И это еще есть try/finally, а вот в Обероне и того нет. Лучший, блин, язык все времен и народов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".
Ну, я надеялся, что ты справишся с нажатием на F5.
MS>Ты, Влад, похоже вообще не понимаешь о чем речь. Поясняю еще раз. Этот "битмаповый карандаш" — это как раз тот самый объектно-ориентированный фуфел, который нафиг никому не нужен в реальности — это чисто обманка. В всяком случае, я не видел ни одного человека, которому хоть раз бы понабодилось нарисовать произвольную линию таким образом.
Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.
MS>Нужно вот что: MS>
Спору нет, это красиво. Спору нет, ты не зря ешь свой хлеб. Но и то что есть в GDI+ тоже востребовано и довольно круто по сравнению с GDI.
Собственно я тебе уже предлагал сделать альтернативу GDI+ на базе твоей либы. Но все это, согласись, немного из другой темы. Мы ведь говорим об ООП и выделении памяти. Не правда ли?
VD>>Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.
MS>Дизайн моей библиотеки выполнен в соответствии с классическими объектно-ориентированными канонами. И тем не менее, никаких иерархий классов там нет. Не нужны они.
Я не видел твоей библиотеки, но вроде бы даже ты сам признавал, что она слишком низкоуровенвая. В общем, я за карсивые иерархии классов которые уменьшают сложность использования библиотек, но не замедляют их работу.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>Есть объекты с детерминирванным временем жизни. CS>Детерменированность как информация это то качество которое мы теряем при отданнии их на откуп GC.
Не могу согласиться с этим утверждением. Время жизни объектов в системах с GC вполне детерминировано и определяется наличием живых ссылок на этот объект.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Все слова про объекты и их экономию просто смехотворны. За время отрисовки таких объектов может возникнуть, ну, десятки, ну, сотни, в параноидальных случаях тысячи. Все это для GC не цифры.
Другое дело ручное управление ресурсами. Вот тут я соглашусь, что лучше бы чтобы все ресурсы ОС освобождались бы одним вызовом. Но для этого совершенно не нужно скрывать объекты в недрах того же Graphics. Это ведь порождает очень некрасивый структурный (не ОО) код и проблемы с производительностью, так как повторное создание хэндлов в ОС отнюдь не дешево.
Я вот опробовал другую идею. В Graphics кэшируются реальные ресурсы выделяемые ОС. А все объекты вроде Font, Brash и т.п. только хранят их описание. Внутри Graphics имеются банальные хэш-таблицы ассоциирующие эти объекты с хэндлами ОС. Причем ассоциирующие по значению, а не по ссылке, так что два одинаковых по описанию фрифта будут ассоциированны с единым хэндлом. В Dispose() Graphics-а происходит перебор этих хэш-таблиц и освобождение ресурсов. В итоге скорость отрисовки ничем не отличается от твоего варианта, но при этом код можно писать в ОО-стиле не заморачиваясь переходом к откровенно С-шному стилю программирования.
За одно решается целый рад проблем, вроде устранения повторного создания и выбора в DC хэндлов ОС.
Код же при этом получается даже проще чем в GDI+ (за счет того, что не нужно делать диспозы всем вспомогательным объектам).
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Brush S>Сыплю. Лень было проверить. S>Однако первый же взгляд туда выдает причины, по которым кисть таки не сделали структурой: от нее пять наследников, а вэлью-типы не поддерживают полиморфизм.
1) А зачем там полиморфизм?
2) Базовые примитивы UI должны быть максимально эффективными.
3) Если нужно нечто выдающееся, например для векторной графики, то делают GraphicsEx
со всеми наворотами, рисованием в буфер и пр. Но не стреляют главным калибром по воробьям.
То что графика в .NET "сакс" это не я придумал.
Т.е. она идеологически правильная но практически не работает — тормозит.
S>Тут возникает такой занятный вопрос — а как добиться в твоем коде эффекта, аналогичного, к примеру, LinearGradientBrush? S>Тут одним static class Color не обойдешься.
Посмотри на список конструкторов. В моем случае это
будет простой набор методов
Graphics.setGradientBrush(...) Это если оно надо.
Полиморфизм вещь хорошая, но там где он нужен. Все — в меру. Как всегда.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, vitaly_spb, Вы писали:
_>>То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.
MS>Читай внимательнее. GC не может этого сделать в принципе, поскольку он знает только о managed ресурсах, объем которых близок к нулю. А вот что там кроется в unmanaged — он не знает и знать не может. И нет никакой возможности передать ему это знание.
2. The GC could/would be triggered by various low-resource memory
notifications by the OS.
/.../
In the process, if resource consumption levels appear high
or a new resource usage threshold is hit, the garbage collector is triggered
to flush the caches.
CS>В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их. Как следствие система жутко не эффективная. Как правило Brush это обертка над системным HBRUSH в конце концов. Т.е. к тому же имеем еще и dispose со всеми вытекающими.
Такая вот мысль в голову пришла. Просьба сильно за нее не бить, если что я не додумал.
А почему бы в языках, работающих в управляемой среде (Java, C#) не разрешить вторичный вызов конструктора ?
class C
{
C(...) {...}
}
C c = new C(1 набор параметров);
// использовали
reconstr (c, C(другой набор параметров));
// естественно, exception, если тип c не есть C)
и т.д.
Конечно, это можно и сейчас сделать, вынеся код в отдельную функцию и вызывая его в первый раз из конструктора, а потом просто так. Но ИМХО это было бы логичнее. Т.е. я пересоздаю объект без перевыделения памяти.
В С++ это, естественно, невозможно, а в управляемой среде ИМХО нет противопоказаний. Ставшие мусором объекты из прежнего экземпляра скушает GC.
Полиморфизма так, конечно, не добьешься, но вот от перевыделения памяти иногда можно избавиться
Brush br = new Brush(Color(0,0,255));
// use blue brush
reconstr (br, Brush(Color(255,0,0));
// use red brush
Здравствуйте, IT, Вы писали:
N>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
IT>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями...
Здравствуйте, n0name2, Вы писали:
N>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями...
Только тут надо иметь в виду что стек не резиновый...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я имел в виду без вызова деструктора.
Не забывай про финалийзеры. И про то что на объект могут быть ссылки.
Короче такая функциональность приведет к граблям. Пусть уж лучше этим оптимизатор занимается ибо в управляемых средах у него достаточно информации для таких оптимизаций.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, n0name2, Вы писали:
N>>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
IT>>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
N>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями...
При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
В задаче своевременного никак не помогают, они помогают в задаче гарантированного освобождения ресурсов. Но вопрос собственно ставился по-другому, а именно: "в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?".
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, reductor, Вы писали:
R>В окамле это давно работает
Работает или есть и иногда при очень удачном стечении обстоятельств используется? Сдаётся мне, что там столько НО!, что в реальном коде это почти не может быть использовано.
R>теперь вот до Жабы на третьи сутки дошло
Ну дай то бог
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pzz, Вы писали: Pzz>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем Pzz>более, что в форточках 1) процесс обычно имеет 2 GB адресного Pzz>пространства, а не 3, как в линухе 2) в форточках потоками принято Pzz>пользоваться активно.
В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем? А в обычных случаях рекурсии (типа обхода дерева) такие глубины на практике недостижимы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pzz, Вы писали: Pzz>Это если считать, что программисты — люди разумные. Однако бывают и Pzz>такие, которые на стеке большие буфера заводят...
Гм. Если вернуться к контексту дискуссии, то можно вспомнить, что речь не о программистах, а о jit-компиляторе, который принимает решение о размещении некоторых объектов в стеке вместо хипа. И уж он-то вряд ли кинется килобайты выделять.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали: N>не совсем. копировать их ненадо, но, все-таки нужно проанализировать граф ссылок и чем больше мертвых и живых обектов тем это сложнее.
Пардон, лично мне казалось, что в графе ссылок обходятся только живые объекты. Я что, ошибаюсь?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Ну... если речь о slid-brush, то да. А если о PathGradientBrush, да еще и с Blend/ColorBlend + TransformationMatrix, то аттрибутов много. Учитывая, что Brush — это все-таки абстракция GDI (св-ва заливки), то все простые и сложные случаи выделили в один класс. Pen — тоже самое. И его можно создавать на основе Brush в т.ч..
+1
V>В Java есть своя изюминка. "Маленькие" объекты, область видимости которых не выходит за локальный контекст, JavaVM частенько располагает прямо на стеке. Жаль, что .Net VM пока не умеет аналогичное.
Это называется escape-аанализом. Обещено только в ява 1.6. Так что пока-что этого нет. Но когда появится... боюсь у многих С++-ников будет сильный шок.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Заведи глобальный счетчик дорогих объектов. Как только этот счетчик превысит некоторое пороговое значения -- вызывай GC (в конструкторе класса).
Лучше этого не делать. В МС и так занимаются магией для хэндлов. Погляди под Рефлектором класс System.Runtime.InteropServices.HandleCollector. А воспользоваться им можно через System.Runtime.InteropServices.HandleCollector.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
N>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
IT>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
Данная фича никак не может быть источником багов, так как она прозрачна для программиста. Программист никогда не узнает, что объекты размещены в стеке. Первая попытка получить указатель из вне метода приведет к тому, что объект станет размещаться в хипе.
Вот только эта фича не обещает появления ни диструкторов, ни даже using-а. Так что причем тут этот аргумент не понятно.
Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Он таки резиновый, хотя, естественно, и ограничен доступной памятью, в языках, в которых стек это деталь реализации. Например, кадры активации в ST, могут для скорости работы мапится на стек, а при исчерпании такового, "материализоваться" в полноценные объекты и переезжать в кучу, освобождая стековое пространство.
Это если где-нить внизу не попадется неуправляемый стековый фрэйм.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.
Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят. Так что наличие большого количества хэндлов автоматом приводит к сборки мусора с последующей финализацией повисших хэндлов.
Как говорится: Если у вас параноя — это еще не означает, что за вами не следят.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Но на время отдельных фаз (в зависимости от режима) GC все потоки приостанавливаются,
Они и так останавливаются. Таковы алгоритмы на сегодны.
ПК>и Finalize определенно замедляет GC.
Они способствуют переносу объектов в первое/второе поколение. Вызов финалайзера мало чем отличается от вызова виртуального метода. Просто затраты на регистрацию/дерегистрацию и вызов финалайзера намного больше чем просто созодать объекто а забыть про него. Но делая тоже самое вручную ты получишь примерно такой же оверхэд.
К тому же грамотно написанныйе обертки совмещаются финалайзеры с диспозами которые вынимают объекты из очереди финализации. Тем самым объекты никуда не продвигаются и разбираться с ними очереди финализации не нужно отдельно не нужно. Зато имеем подстраховку в том смысле, что некритичные хэндлы умрут даже если о них забл программист.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.
Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Нужен. Но что-то у меня в голове большинство оптимизацй сводятся к отказу от размещения объекта в стеке. Если можешь приведи мне пример, когда это реально, чтобы сдвинуть мою приторможенную фантазию с места.
Любая ситуация где джит может вычислить, что массив или объект используется только в рамках метода и вложенных в него методов может привести к тому, что объект/массив будет расположен в стеке. Причем если у объекта/массива есть потомки, то и их можно бросить в стэк. При этом если извесно, что нет обращений через рефлекшон и передачи ссылок во вне, то можно отказаться и от оврехеда в заголовках типов (они ведь умрут вместе с фрэймом стека).
В итоге большинство маленьких объектов и массиво смогут лечь в стэк. При этом скорость будет даже выше С++-ной, так как у них отсуствуют деструкторы и зачастую кострукторы.
Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VD>>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить. IT>Очень похоже на оптимизацию по Дворкину.
Оптимизицией по Дворкину занимается программист, а здесь компьютер. Разницу чувствуешь?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
VladD2 wrote:
> C>Останавливают — всю систему. Когда по какой-то причине финализаторы > C>блокируют поток финализации. > Нет. Плевать CLR на этот потох хотел.
А вы попробуйте сделать финализаторы, которые будут блокироваться на
достаточно долгое время. А потом посмотрите что станет с системой, когда
закончатся GUI-описатели.
Вообще, MS надо убить за использование финализаторов для освобождения
критичных ресурсов.
Здравствуйте, McSeem2, Вы писали:
MS>Давай уточним, что ты имеешь в виду под "попиксельным рисованием". Конкретно вызов функции WinAPI SetPixel() или что-то другое? И если что-то другое, то что конкретно?
Я лично работал только с SetPixel (или как там его) и еще ручной модификацией битмапа. В последнем случае откровенно задолбался с индексированными цветами. Первый тормозил не под детский. А главное, что необходимость делать (лично мне) подобные низкоуровневые опрерации в общем-то равна нулю.
Лично ты, насколько мне известно, как раз занимаешся софтовой работой с графикой на низком уровне. Тебе может этот способ и подойдет. Но нам с ИТ рисование пикселей может понадобиться тольк разве что в каком-нибудь движке отчетов. А там такой низкий уровень явно избыточен.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Понимаш ли, мне плевать какой там карандаш. Он рисует не смотря на то является ли он монотонным или картинкой.
Карандаш картинкой? Это явный гон. Никто такого не умеет делать, только я умею, да и то со значительными ограничениями. Нарисовать линию паттерном в виде произвольного битмапа, да еще и с фильтрацией — это не просто задача, это — мегазадача. Изобретение карандашей по сравнению с такой задачей — это детская песочница, не стоящая упоминания.
То есть, получается так, что для рисования таких сложных вещей карандаши — это мелочь. А вот для сплошных цветов они портят жизнь, точно так же, как портила бы жизнь необходимость каждую переменную создавать через new.
VD>Я вот вспоминаю первые книжки по ООП где в качестве примера давались иерархии классов графических приметивов. Там примитивы и получали точки. Брали точки и получали фигуры... В конеце получали все что угодно. Красиво... но не эффективно.
Тебя обманули, ООП заключается вовсе не в этом. Не спрашивай меня, в чем оно заключается, но могу сказать, что точно не в иерархиях классов.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
MS>>Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".
VD>Ну, я надеялся, что ты справишся с нажатием на F5.
Твой код не компилируется. О, это была пестня. Сейчас насмешу. Ну запустил я студию (2003), создал новый C# Windows App. Дальше что? Копируем класс из твоего сообщения. Что за слово "partial"? Не знаем такого. Ладно, убираем. Но какую кнопку надо нажать, чтобы в Properties.Resources образовался Image1? Я такой не нашел. Но до этого дело даже не дошло — оно жалуется "System.Windows.Forms.Control.Properties is inaccessible due to its protection level". Это навеяло мне древнюю бодягу с MFC. Сначала там все данные и многие функции были private. Но с каждой новой версией все становилось все более и более public. И сейчас я тоже испытал мощное дежа-вю.
Но ладно, я решил, что можно и вручную загрузить. Смотрим класс Image и не находим у него ни конструктора с именем файла, ни метода Load. Ищем в интернете TextureBrush, находим, что надо использовать не Image, а Bitmap. Хорошо, пишем Bitmap bmp = new Bitmap("1.bmp"); и получаем облом — исключение. Оно не находит файла в каталоге проекта (какой там текущий каталог — я не знаю и как это выяснить — тоже не знаю). Поскольку нам надо только проверить, пишем абсолюный путь. И вот только теперь у нас все получилось.
Какая-то бесталанность во всем этом присутствует, вот за что я не люблю дот-нет — на выяснение самых элементарных вещей уходит уйма времени. А спросить стыдно — засмеют
VD>Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.
Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Твой код не компилируется. О, это была пестня. Сейчас насмешу. Ну запустил я студию (2003), создал новый C# Windows App. Дальше что? Копируем класс из твоего сообщения. Что за слово "partial"? Не знаем такого.
ключевое слово: net 2.0. (Ты же не стал бы обижаться, если бы примеры из страуструпа отказались компилироваться на Classic С Compiler?). MS>Ладно, убираем. Но какую кнопку надо нажать, чтобы в Properties.Resources образовался Image1? Я такой не нашел. Но до этого дело даже не дошло — оно жалуется "System.Windows.Forms.Control.Properties is inaccessible due to its protection level". Это навеяло мне древнюю бодягу с MFC. Сначала там все данные и многие функции были private. Но с каждой новой версией все становилось все более и более public. И сейчас я тоже испытал мощное дежа-вю. MS>Но ладно, я решил, что можно и вручную загрузить. Смотрим класс Image и не находим у него ни конструктора с именем файла, ни метода Load.
Гм. А как же Image.FromFile()? MS>Ищем в интернете TextureBrush, находим, что надо использовать не Image, а Bitmap. Хорошо, пишем Bitmap bmp = new Bitmap("1.bmp"); и получаем облом — исключение. Оно не находит файла в каталоге проекта (какой там текущий каталог — я не знаю и как это выяснить — тоже не знаю).
Гм. Боюсь тебя разочаровать, но эта проблема никакого отношения к дотнету не имеет. Это винда. Текущий каталог может показывать куда угодно. Я не очень понимаю, что именно ты имел в виду, когда указывал относительный путь. Тем более этого не понимает винда. MS> Поскольку нам надо только проверить, пишем абсолюный путь. И вот только теперь у нас все получилось.
Все правильно. Если бы нам надо было реализовать какое-то другое поведение, то понадобилось бы сначала его продумать, а уже потом реализовывать.
Например, я бы этот битмэп вставил как Embedded Resource, и грузил через Image.FromStream(Assembly.GetManifestResourceStream()). MS>Какая-то бесталанность во всем этом присутствует, вот за что я не люблю дот-нет — на выяснение самых элементарных вещей уходит уйма времени. А спросить стыдно — засмеют
И правильно, что стыдно. Потому что в дотнете как раз все очень логично и интуитивно понятно. Но эта интуиция забесплатно не дается. Хотя по сравнению с тем, сколько времени я убил на разбирательство с логикой #include при ознакомлении с С++, тонкости дотнета — это децкий лепед. Просто ты привык к определенным особенностям, и используешь их не задумываясь. Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.
VD>>Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.
MS>Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.
Опять ты смешиваешь архитектуру и реализацию. Вот не надо переносить косяки реализации на архитектуру. Да, парни, которые реализовывали это дело — халтурщики. И что теперь, выкидывать базовый класс из-за того, что есть убогие наследники?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали:
N>ок, как часто происходит сборка нулевого поколения? сколько раз в секунду?
В зависимости от того как приложение работает с памятью. Может 100 раз в секунду, а может и раз в час. N>предположим что есть пул со 50ю соединениями и есть нагрузка от 10 до 200 запросов/сек (совершенна типичная ситуация для задач которые обычно решаются на Жабе). вот у нас настал пик и мы потеряли за 0.25с все 50 соединений. неужели сборка 0го поколения происходит настолько часто (у меня в приложениях это бывает ну раз в минуту примерно)? и если да то какова вероятность попадения соединения в 1е/2е поколенье?
Нормальные люди используют using и соеденения возвращаются в пул сразуже после того как с ним поработали.
Просто Влад говорит о том что если гдето какойто разбдолбай забудет это сделать то ГЦ за ним приберет.
N>я правильно понял что ты предлагаешь в реализацию пула встраивать механизм который ЗНАЕТ о существовании ЖЦ?
А почему бы и нет? N>это же жуть какая-то! тут кода/оверхеда будет на порядок больше чем от какого-то там try/finally. ну предположим что он дернет ЖЦ — мол собирай. N>а можно сказать какое именно поколенье нужно собирать
Можно. N>или это вызовет полную сборку мусора и остановку всего приложения более чем на секунду что совершенно неприемлемо (в любом уважающем себя Жабном приложении полная сборка не происходит никогда, разве что пару раз на стартапе).
Быть может в жабе сборка мусора и занимает секунду но в .НЕТ даже полная сборка происходит на порядки быстрее.
N>кроме того, (хотя лично я и не люблю ОРМ) многие пользуются отличными продуктами для доступа к БД (Hibernate, JDO, EJB3, из которых для .НЕТ есть только альфа NHibernate) в виде объектов, там API уровнем намного выше.
А для .НЕТ есть RFD RFD в реальных проектах
N>кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе.
Гм... а зачем что-то еще вызывать?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, McSeem2, Вы писали:
WH>> public static void AddMemoryPressure(long bytesAllocated);
MS>Спасибо, но это не совсем то. Оно глобальное и работает только с памятью. А прочие ресурсы?
На самом деле чиселка bytesAllocated довольно абстрактная. В бета-версиях фреймворка писали, что это просто число, чем оно больше тем важнее быстрее его прибить. Использовать можно не только для больших кусков памяти, но и для любых дорогих ресурсов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Для этого нужно чтобы вызов вышел из неуправляемой среды и вернулся назад. Имхо, в виду претензии управляемой среды на самодостаточность, чаще всё заканчивается на первом шаге.
Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Denis_TST, Вы писали:
D_T>>А вот GDI+ точно троечники писали . Не понимаю почему 250 сглаженных линий толщиной 2px рисуются ~0.3 секунды. D_T>>AntiGrain делает это за 30 ms.
VD>Думаю, они рассчитывали на то что эта операция будет осуществляться аппоратно. Ведь 30 мс — это тоже неприемлемо много.
Да , после релиза GDI+ говорилось про аппаратную реализацию. Но потом пришел Avalon и все испортил
CS>"Все — managed" это имхо грубейшая ошибка дизайна которая например убила Java UI на корню.
разработчики Java UI (swing) неправильно оценили свою задачу. Они создавали swing не как базовую библиотеку, а как обычный проект из некоторой предметной области.
Тому, кто будет использовать библиотеку позволительно меньше задумываться о ресссурсах и больше сосредоточится на предмете
Поэтому грамотное написании базовой библиотеки нацелено прежде всего на удобство использования, экономичность и максимально высокую производительность. У тех кто разрабатывал swing этого понимания небыло.Так и плодятся самые разные проекты . Архитектурно гараздо более удачные.
CS>.NET UI (WinForms) слепо содрав подход AWT/SWT успешно двигается в
и это правда
CS>том же самом направлении.
CS>Вот такие вот мои мысли в слух если они кому интересны.
очень интересно, надо бы с тобой поближе познакомиться
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их.
IT>Rect в .NET — это value type. Соответственно GC тут не при чём.
Да в .NET c этим чуть лучше. Но не радикально.
IT>Проблема с Brush только одна — его нужно диспозить. Занимаемая ею память на эффективность программы никак не повлияет.
И я о том. А зачем собственно. Говоря о brush, кому-нибудь нужна эта самая brush как объект с атрибутами? Вряд ли.
А в тех случаях когда да, то сделать себе простой value тип — описатель — три секунды.
IT> Ну запустится GC не три раза за время работы программы, а четыре
При отработке события WM_PAINT jsmile-demo.exe вообще ничего не аллоцирует в Java коде ибо не требуется.
reductor wrote:
> У O'Camla тут интересное решение в виде двух куч — малой, для > короткоживущих объектов. И большой — понятно для чего.
Боже мой! Это "интересное решение" давно уже используется в мире
Java/C#, называется "generational garbage collection". Причем намного
эффективнее, чем в OCaml'е.
А если бы вы удосужились прочитать ту ссылку на старую тему на RSDN,
которую я давал вам, то и таких вопросов бы не возникало.
Кстати, даже консервативный Boehm GC поддерживает сборку в разных
поколениях.
> Каким-то образом это пересекается с идеей регионов у cyclone — там > нечто вроде стека из куч > Еще очень интересное направление — это region inference, когда > копилятор статически определяет все точки на стеке, где есть ссылка на > объект и освобождает память там, где объект выходит за пределы видимости.
Здравствуйте, Cyberax, Вы писали:
C>Боже мой! Это "интересное решение" давно уже используется в мире C>Java/C#, называется "generational garbage collection". Причем намного C>эффективнее, чем в OCaml'е. C>Читать ХОТЯ БЫ http://www.codeproject.com/dotnet/garbagecollection.asp . C>А если бы вы удосужились прочитать ту ссылку на старую тему на RSDN, C>которую я давал вам, то и таких вопросов бы не возникало. C>Кстати, даже консервативный Boehm GC поддерживает сборку в разных C>поколениях. C>Это элементарно делается с помощью пулов, временем жизни которых C>управляет автоматическая переменная на стеке. Применительно к Java это C>сделано в http://www-rocq.inria.fr/arles/doc/ps02/RT-journal.pdf .
Так, на секундочку, вам не кажется, что вы немножко не на то сообщение ответили?
Или что не прочитали перед тем как отвечать, уж не знаю.
Просто буря какая-то эмоций.
В случае с окамлом и с другими, смысл в том, что как время жизни и прочее определяется _статически_ компилятором.
И что окамл кладет значения не только на кучу.
А что inria (институт, в котором делают ocaml) много технологий родила и для java много делает я в курсе.
Сам Xavier Leroy много где в java-технологиях отметился.
reductor wrote:
> В случае с окамлом и с другими, смысл в том, что как время жизни и > прочее определяется _статически_ компилятором. > И что окамл кладет значения не только на кучу.
А это называется escape analysis, и тоже замечательно используется в
Java/C# (а в С++ заменяется автоматическими объектами). Причем в новой
Java Hotspot JVM 1.6 оно еще будет привязано к механизму hotspot.
> А что inria (институт, в котором делают ocaml) много технологий родила > и для java много делает я в курсе.
Generational GC примерно лет на 15 старше OCaml'а.
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> В случае с окамлом и с другими, смысл в том, что как время жизни и >> прочее определяется _статически_ компилятором. >> И что окамл кладет значения не только на кучу.
C>А это называется escape analysis, и тоже замечательно используется в C>Java/C# (а в С++ заменяется автоматическими объектами). Причем в новой C>Java Hotspot JVM 1.6 оно еще будет привязано к механизму hotspot.
Ну и? Тема-то текущая про что вообще? Или вы по интерции?
>> А что inria (институт, в котором делают ocaml) много технологий родила >> и для java много делает я в курсе.
C>Generational GC примерно лет на 15 старше OCaml'а.
Во-первых, не на 15.
Во-вторых, у O'Caml не просто Generational GC
В-третьих, тут в данной ветке речь не о том, а посмотрите о чем.
Здравствуйте, reductor, Вы писали:
R>У O'Camla тут интересное решение в виде двух куч — малой, для короткоживущих объектов. И большой — понятно для чего. R>+ Естественно, все достаточно маленькие значения он кладет туда, куда нужно сразу.
...
Мой пост немного о другом.
Есть объекты с детерминирванным временем жизни.
Детерменированность как информация это то качество которое мы теряем
при отданнии их на откуп GC.
В целом система получается неоптимальной.
Есть задачи в которых "только GC" (generational или нет, не важно)
работает. Но задачи UI не из их числа. Там нужно оба подхода.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>При отработке события WM_PAINT jsmile-demo.exe вообще ничего не аллоцирует в Java коде ибо не требуется.
IT>А для .NET версия есть?
Нет. И я задачи такой не ставил. j-smile делался мной когда на
меня нагрузили руководство созданием системы с Java UI.
Т.е. в том числе я пытался понять как оно там внутри работатет.
Вторая гипотеза которая проверялась — можно ли сделать
встраиваемую VM чтобы не заморачиваться проблемами
совместимости с установленными JRE.
Ну и про третью я уже сказал. Память и работа с ней.
Здравствуйте, c-smile, Вы писали:
CS>В данном случае Java выполняет менджмент микро объектов Rect и Brush — создает и удаляет их. Как следствие система жутко не эффективная. Как правило Brush это обертка над системным HBRUSH в конце концов. Т.е. к тому же имеем еще и dispose со всеми вытекающими. CS>Brush как отдельный объект никому не нужен. Как правило все что с ним делается это вызывается конструктор и все. CS>Rectangle в общем-то тоже как самостоятельный объект представляет мало ценности. Тогда зачем они? (см. далее про j-smile)
Я так понимаю, что в .Net и Brush и Rectangle — value типы. Которые сделаны как раз для того, чтобы не напрягать GC. Имеем честную стековую аллокацию, прозрачную интеграцию c GC (структуры, лежащие в стеке, могут быть корнями для reference — объектов), возможность пользоваться методами, в том числе и виртуальными. Благодаря этому, эффективность метода, использующего новый Brush, вряд ли ниже его pure-C аналога. Потому что ничего лишнего не делается.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
CS>Brush
Сыплю. Лень было проверить.
Однако первый же взгляд туда выдает причины, по которым кисть таки не сделали структурой: от нее пять наследников, а вэлью-типы не поддерживают полиморфизм.
Тут возникает такой занятный вопрос — а как добиться в твоем коде эффекта, аналогичного, к примеру, LinearGradientBrush?
Тут одним static class Color не обойдешься.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
CS>1) А зачем там полиморфизм?
Если честно, то я с System.Drawing еще вообще не разбирался (отсюда и глупые ошибки). Поэтому не могу сказать, насколько там оправдан полиморфизм.
S>>Тут возникает такой занятный вопрос — а как добиться в твоем коде эффекта, аналогичного, к примеру, LinearGradientBrush? S>>Тут одним static class Color не обойдешься. CS>Посмотри на список конструкторов.
Посмотрел. CS>В моем случае это CS>будет простой набор методов CS>Graphics.setGradientBrush(...) Это если оно надо.
А, то есть ты предлагаешь сделать в Graphics по методу на каждый конструктор одного из потомков кисти? Может быть, оно и оправдано. Хотя я не уверен: дело в том, насколько удобно это будет в применении. У тебя не будет возможности в одном месте решить, какой кистью закрашивать, а в другом — какую фигуру нарисовать. Так бы ты сделал метод DrawRectangle, принимающий параметры прямоугольника и кисть, которая взята откуда-то снаружи (из преференсов пользователя, к примеру). И он бы работал для всех кистей, независимо от того, в каком порядке что вызывалось. А при твоем способе нужно следить за тем, чтобы ненароком не испортить состояние Graphics лишним вызовом setXXX(). CS>Полиморфизм вещь хорошая, но там где он нужен. Все — в меру. Как всегда.
Верно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
CS>Вот такие вот мои мысли в слух если они кому интересны.
Мысли интересны, но не кажется ли тебе, что это можно выразить короче ? А именно — для достаточно часто выполняемых коротких операций не надо дергать кучу , если это возможно и не противоречит высшим идеям При этом неважно, управляемая она или нет. Твой пример можно вполне на неуправляемый С++ перевести, и он там будет так же точно выглядеть, только явный вызов delete добавится. И эффекты будут те же — по скорости.
У меня, кстати, этот вопрос постоянно с моими студентами возникает. То и дело вижу у них такое
Здравствуйте, c-smile, Вы писали:
CS>И я о том. А зачем собственно. Говоря о brush, кому-нибудь нужна эта самая brush как объект с атрибутами?
Ну... если речь о slid-brush, то да. А если о PathGradientBrush, да еще и с Blend/ColorBlend + TransformationMatrix, то аттрибутов много. Учитывая, что Brush — это все-таки абстракция GDI (св-ва заливки), то все простые и сложные случаи выделили в один класс. Pen — тоже самое. И его можно создавать на основе Brush в т.ч..
IT>> Ну запустится GC не три раза за время работы программы, а четыре
CS>При отработке события WM_PAINT jsmile-demo.exe вообще ничего не аллоцирует в Java коде ибо не требуется.
В Java есть своя изюминка. "Маленькие" объекты, область видимости которых не выходит за локальный контекст, JavaVM частенько располагает прямо на стеке. Жаль, что .Net VM пока не умеет аналогичное.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня, кстати, этот вопрос постоянно с моими студентами возникает. То и дело вижу у них такое PD>POINT* pPoint = new POINT[3]; // именно константа PD>и я уже устал объяснять им, что проще PD>POINT Point[3]; PD>
Ну это не то чтобы проще. Я в свое время помнится старался тщательно объяснить студентам основные паттерны освобождения памяти с точки зрения времени жизни. Типа идея в том, что чем больше мы отдадим RTL информации о порядке освобождения наших ресурсов, тем лучше он станет работать:
— статические объекты, которые вообще не надо освобождать.
— автоматические объекты, которые освобождаются всегда в порядке, обратном выделению
— динамические объекты, которые освобождаются в произвольном порядке.
(есть и другие паттерны, но я их сам никогда не пользовал )
С этой точки зрения, дело не столько в том, что поинты маленькие и им будет хорошо на стеке, сколько в том, что они не нужны сразу по выходу из текущего скоупа.
Т.е. POINT Point[3] — не проще, а точнее.
Принудительное размещение таких объектов в динамической памяти не дает шанса схитрить на их освобождении. Есть примеры библиотечных классов, которые принимают решение о размещении на стеке либо в хипе в зависимости от параметров конструктора.
З.Ы. К сожалению, не везде можно быть столь оптимистичным. Я вот помню свою первую программу на С++. Я там попытался сохранить содержимое текстового экрана для восстановления при выходе из программы, и тут же нарвался на переполнение стека. Я уж и не помню, какая там была модель памяти, но 4 килобайта на стеке ее моментально убили . Преподаватель мне тогда накрепко сказал, что в стеке можно выделять только что-нибудь крошечное. Если бы я только знал про полноценные библиотеки в те времена...
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ну это не то чтобы проще. Я в свое время помнится старался тщательно объяснить студентам основные паттерны освобождения памяти с точки зрения времени жизни. Типа идея в том, что чем больше мы отдадим RTL информации о порядке освобождения наших ресурсов, тем лучше он станет работать:
+1
S>- статические объекты, которые вообще не надо освобождать. S>- автоматические объекты, которые освобождаются всегда в порядке, обратном выделению S>- динамические объекты, которые освобождаются в произвольном порядке. S>(есть и другие паттерны, но я их сам никогда не пользовал )
М-да... Я как-то об этом знал до того, как услышал вообще слово "паттерн" . Впрочем, на Фортране был тогда только первый тип...
S>С этой точки зрения, дело не столько в том, что поинты маленькие и им будет хорошо на стеке, сколько в том, что они не нужны сразу по выходу из текущего скоупа. S>Т.е. POINT Point[3] — не проще, а точнее.
Эффективнее . Вот тебе простой пример
for(int i = 0; i < 1000; i++)
{
POINT* p = new POINT [3];
// и т.д.
delete [] p;
}
for(int i = 0; i < 1000; i++)
{
POINT p[3];
// и т.д.
}
1000 раз дергать кучу там, где можно и один раз не дергать — хорошая, кстати иллюстрация на тему микрооптимизации, за которую меня некоторые ругали . Вот таким невиинным кодом убивают производительность. А с точки зрения дизайна здесь вообще ничего нет — дизайн здесь близко не лежит.
Конечно, я здесь использую свое знание того, что выделение памяти в стеке произведено будет 1 раз, а не 1000 (кстати, это стандартом ИМХО не определяется, формально ведь память отводится при входе в блок, так ?). Но даже если бы 1000 раз — все равно лучше 1000 раз выполнить что-то вроде add esp,..., чем 1000 раз дергать хип менеджер с его поиском в 2-linked списке.
S>З.Ы. К сожалению, не везде можно быть столь оптимистичным. Я вот помню свою первую программу на С++. Я там попытался сохранить содержимое текстового экрана для восстановления при выходе из программы, и тут же нарвался на переполнение стека. Я уж и не помню, какая там была модель памяти, но 4 килобайта на стеке ее моментально убили . Преподаватель мне тогда накрепко сказал, что в стеке можно выделять только что-нибудь крошечное.
Ну не знаю. Никакой проблемы в этом не было, размер стека в любой модели, (кроме tiny, где все вместе в 64К), был ограничен 64 К. Надо было просто _stklen установить. В конце концов никто на запрещщал же в те времена вот такие описания
Здравствуйте, McSeem2, Вы писали:
MS>Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует. Не понял что ты хочешь. unmanaged потому так и называется, потому как не контролируем. Это его сильная сторона. И ты можешь спокойно реализовать свой механизм управления памятью.
Здравствуйте, GlebZ, Вы писали:
GZ> Не понял что ты хочешь. unmanaged потому так и называется, потому как не контролируем. Это его сильная сторона. И ты можешь спокойно реализовать свой механизм управления памятью.
Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Сергей Губанов, Вы писали:
MS>>... вот у меня unmanaged объект ... ... получается тот же ручной malloc/free!
СГ>Для unmanaged объекта ручной malloc/free — очень странно, не правда ли?
Не понял сарказма. В своей практике на С++ я уже очень давно не пользуюсь ни malloc/free, ни new/delete. Точнее сказать, пользуюсь, но крайне редко и на самом нижнем уровне. Есть такая парадигма RAII. А дот-нетовский GC в этом плане — это возврат к сишным malloc/free.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, vitaly_spb, Вы писали:
_>То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.
Читай внимательнее. GC не может этого сделать в принципе, поскольку он знает только о managed ресурсах, объем которых близок к нулю. А вот что там кроется в unmanaged — он не знает и знать не может. И нет никакой возможности передать ему это знание.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Лично меня в дот-нете сильно напрягает нечто другое. Вот придумали они механизм взаимодействия managed-unmanaged. И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP". Приходится явно удалять самому — вызывая Dispose или через using, иначе цикл из 10000 итераций отъедает 100-200 мег. Но это получается тот же ручной malloc/free! За что, спрашивается боролись? Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
public static class GC
{
// Summary:
// Informs the runtime of a large allocation of unmanaged memory that should
// be taken into account when scheduling garbage collection.
//
// Parameters:
// bytesAllocated:
// The incremental amount of unmanaged memory that has been allocated.
//
// Exceptions:
// System.ArgumentOutOfRangeException:
// bytesAllocated is less than or equal to 0.-or-On a 32-bit computer, bytesAllocated
// is larger than System.Int32.MaxValue.
//
// System.InvalidOperationException:
// The total amount of memory pressure exceeds System.UInt64.MaxValue.public static void AddMemoryPressure(long bytesAllocated);
//
// Summary:
// Informs the runtime that unmanaged memory has been released and no longer
// needs to be taken into account when scheduling garbage collection.
//
// Parameters:
// bytesAllocated:
// The amount of unmanaged memory that has been released.
//
// Exceptions:
// System.ArgumentOutOfRangeException:
// bytesAllocated is less than or equal to 0. -or- On a 32-bit computer, bytesAllocated
// is larger than System.Int32.MaxValue.
//
// System.InvalidOperationException:
// The total amount of memory pressure is less than zero.public static void RemoveMemoryPressure(long bytesAllocated);
}
Ы?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
ИМХО, финалайзеры это чрезвычайно дурной стиль. закрытие системных ресурсов надо делать явно вызывая .close() на объекте а не ждать пока ЖЦ его подберет.
в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
public Point create(int x, int y) { return new Point(x, y); }
public void draw(Point p, Point pp) { Magic.doDrawLine(p.x, p.y, pp.x, pp.y); }
public static void main(String [] args) {
Point p = create(0, 0), pp = create(100, 100);
draw(p, pp);
}
McSeem2,
> Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
Не уверен, насколько это работает, но многие рекламируют Safe Handles из .Net FW 2.0.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, McSeem2, Вы писали:
MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
Эээ. Такого и у менеджед нету. А нету по одной простой причине. Для любого GC важно есть объект, или его нет. Жив или мертв. Остальные вопросы неважны. В остальном — объекты для GC это всего-лишь память которую надо обслуживать, да иногда запускать финализатор. Ему наплевать на наискорейшее удаление. Ему важно сколько памяти осталось.
Если можно легко определить на менеджед, живой ли объект, то сделать менеджер памяти по тому же принципу на C++ достаточно легко. Просто проверяешь размер текущего хипа, и если он превышает определенный параметр, то запускаешь стандартный GC.Collect от Net. Который параллельно будет вычищать как менеджед, так и unmanaged на финализаторах.
Здравствуйте, Sinclair, Вы писали:
CS>>В моем случае это CS>>будет простой набор методов CS>>Graphics.setGradientBrush(...) Это если оно надо. S>А, то есть ты предлагаешь сделать в Graphics по методу на каждый конструктор одного из потомков кисти? Может быть, оно и оправдано. Хотя я не уверен: дело в том, насколько удобно это будет в применении. У тебя не будет возможности в одном месте решить, какой кистью закрашивать, а в другом — какую фигуру нарисовать. Так бы ты сделал метод DrawRectangle, принимающий параметры прямоугольника и кисть, которая взята откуда-то снаружи (из преференсов пользователя, к примеру). И он бы работал для всех кистей, независимо от того, в каком порядке что вызывалось. А при твоем способе нужно следить за тем, чтобы ненароком не испортить состояние Graphics лишним вызовом setXXX(). CS>>Полиморфизм вещь хорошая, но там где он нужен. Все — в меру. Как всегда. S>Верно.
Если действительно нужен полиморфизм здесь то сделать себе поверх этого
class Brush и класс GraphicsEx: public Graphics не представляет проблемы.
Просто это далеко не всегда нужно.
В качесве примера: есть стиль (CSS) у которого в общем случае
четыре border и их brushes, background solid border (+ у меня еще и градиент)
background image brush в разных вариациях и т.д.
Хранить это все безобразие в виде отдельных объектов типа Brush, Color и пр....
Я думаю мысль понятна и продолжать её не надо.
Классовые иерархии вещь конечно хорошая. Если задача в них вмещается. Если же нет — все, труба, они только мешают.
Вот еще пример:
Скажем имея следующий Canvas нужно сделать SVG viewer.
Представим себе что SVG документ загружен в DOM.
Таким образом линейный проход по дереву с простой state machine + эта canvas
это все что нам нужно для rendering. И не нужны там тебе ни Color ни Pen/Brush в виде классов...
Нарисовал — и забыл.
Здравствуйте, McSeem2, Вы писали:
MS>И вот у меня unmanaged объект требует довольно много памяти, а GC об этом ничего не знает и нет никакой возможности ему объяснить, что "этот объект дорогой, его надо подметать ASAP".
Может имеет смысл сделать такие объекты managed?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Эффективнее . Вот тебе простой пример
Все равно точнее. Если мы признаемся себе, что точки нам нужны во всех итерациях, то можно вынести их за цикл:
POINT* p = new POINT [3];
for(int i = 0; i < 1000; i++)
{
// и т.д.
}
delete [] p;
Если бы у точки был нетривиальный дефолтный конструктор, то этот код имел бы шанс быть даже эффективнее твоего варианта:
PD>for(int i = 0; i < 1000; i++) PD>{ PD> POINT p[3]; PD> // и т.д. PD>}
PD>1000 раз дергать кучу там, где можно и один раз не дергать — хорошая, кстати иллюстрация на тему микрооптимизации, за которую меня некоторые ругали . Вот таким невиинным кодом убивают производительность. А с точки зрения дизайна здесь вообще ничего нет — дизайн здесь близко не лежит. PD>Конечно, я здесь использую свое знание того, что выделение памяти в стеке произведено будет 1 раз, а не 1000 (кстати, это стандартом ИМХО не определяется, формально ведь память отводится при входе в блок, так ?). Но даже если бы 1000 раз — все равно лучше 1000 раз выполнить что-то вроде add esp,..., чем 1000 раз дергать хип менеджер с его поиском в 2-linked списке.
Я вот не уверен, что надо начинать рассуждения с add esp и прочих туманных деталей. Я всегда старался запоминать наиболее общие утверждения. К тому же как раз плюсы — штука чреватая неявными эффектами. Да, для точки все действительно так, как ты говоришь. Более того, компилятор как раз способен вынести инвариант за цикл (в отличие от случая с new/delete) и получить код, близкий к оптимальному.
PD>Ну не знаю. Никакой проблемы в этом не было, размер стека в любой модели, (кроме tiny, где все вместе в 64К), был ограничен 64 К. Надо было просто _stklen установить. В конце концов никто на запрещщал же в те времена вот такие описания
PD>void f() PD>{ PD>char a[4096] ; PD>//.... PD>}
Да, никто и не запрещал. Вот только моя программа сразу же упала с таким описанием. Я уже не помню, что там надо было установить.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Pavel Dvorkin,
> А почему бы в языках, работающих в управляемой среде (Java, C#) не разрешить вторичный вызов конструктора ? > > class C > { > C(...) {...} > } > > C c = new C(1 набор параметров); > // использовали > reconstr (c, C(другой набор параметров)); > > // естественно, exception, если тип c не есть C) > > <...> > > В С++ это, естественно, невозможно <...>
Почему?
C* c = new C(1);
. . .
c->~C();
new (c) C(2);
. . .
delete c;
проверку на совпадение типа можно организовать, используя RTTI.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Т.е. я пересоздаю объект без перевыделения памяти.
в Java/C# не нужны ручные оптимизации — все это может делать компилятор или рантайм автоматически. если бы это было действительно узким местом, то давно бы уже так и сделали.
само по себе перевыделение памяти это совершенно бесплатная операция т.к. память не фрагментирована. выделение памяти это просто инкремент одного указателя (даже мутекса нет т.к. у каждого потока свой маленький heap имеется), освобождения как такового тоже нет, просто объект не копируется в следующее поколенье.
единственное что занимает много времени это инициализация объекта (скажем, массивы при выделении инициализируются нулями, ссылки все нулевые и т.д.) но при пересоздании это тоже надо делать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Такая вот мысль в голову пришла. Просьба сильно за нее не бить, если что я не додумал.
PD>А почему бы в языках, работающих в управляемой среде (Java, C#) не разрешить вторичный вызов конструктора ?
Я думаю, потому, что это нарушит ссылочную целостность. У нас уже есть ссылки в других объектах на этот объект. И эти другие объекты будут крайне удивлены внезапной смерти того объекта и возникновению нового. У меня сейчас сильнейшее дежа вю, т.к. данная тема уже точно поднималась.
PD>Конечно, это можно и сейчас сделать, вынеся код в отдельную функцию и вызывая его в первый раз из конструктора, а потом просто так. Но ИМХО это было бы логичнее. Т.е. я пересоздаю объект без перевыделения памяти.
PD>Полиморфизма так, конечно, не добьешься, но вот от перевыделения памяти иногда можно избавиться
Выделение памяти в управляемой среде — сверхестественно дешевая операция, сравнимая со стоимостью выделения памяти на стеке в C++. Не там воду ищешь.
Для тех редчайших случаев, когда действительно дешевле переинициализировать объект, чем создавать новый, можно пользоваться двухстадийной инициализацией.
Brush br = new Brush(Color(0,0,255));
br.Init(Color(0,0,255));
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
WH>Только тут надо иметь в виду что стек не резиновый...
Ага, и то что запросить информацию об объекте и выполнить действия могут через внешний интерфейс типа reflection.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Pavel Dvorkin,
>> А почему бы в языках, работающих в управляемой среде (Java, C#) не разрешить вторичный вызов конструктора ? >> >> <...> >> >> В С++ это, естественно, невозможно <...>
ПК>Почему? ПК>
ПК>C* c = new C(1);
ПК>. . .
c->>~C();
ПК>new (c) C(2);
ПК>. . .
ПК>delete c;
ПК>
Вопрос терминологический, но по-моему, здесь не происходит повторного вызова конструктора
Конструктор чего вызывается повторно? Ведь объект, на который указывает c не существует после вызова соответствующего деструктора
Здравствуйте, WolfHound, Вы писали:
N>>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями... WH>Только тут надо иметь в виду что стек не резиновый...
в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать.
Здравствуйте, n0name2, Вы писали:
N>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать.
Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException.
Вобщем тут не все так однозначно.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
N>>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать. WH>Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException. WH>Вобщем тут не все так однозначно.
вполне верю что где-то выскочит SOE, но, думаю, это будет лечится -Xss10m да и рекурсия в наше время весьма редкий зверь все-таки...
Здравствуйте, WolfHound, Вы писали:
N>>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями... WH>Только тут надо иметь в виду что стек не резиновый...
Он таки резиновый, хотя, естественно, и ограничен доступной памятью, в языках, в которых стек это деталь реализации. Например, кадры активации в ST, могут для скорости работы мапится на стек, а при исчерпании такового, "материализоваться" в полноценные объекты и переезжать в кучу, освобождая стековое пространство.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, n0name2, Вы писали:
N>>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать. WH>Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException. WH>Вобщем тут не все так однозначно.
Я подозреваю, что в современном мире вызвать StackOverflowException можно только по ошибке. Уж очень там лимит зверский стоит.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > > N>>в общем да — ну так рантайм знает в точности сколько что занимает и > совершенно свободно посчитает сколько туда можно пихать. > WH>Вот только может возникнуть проблема с рекурсивными алгоритмами > которые безпроблем выполнялись на предыдущем рантайме, а в новом будут > вываливаться по StackOverflowException. > WH>Вобщем тут не все так однозначно. > Я подозреваю, что в современном мире вызвать StackOverflowException > можно только по ошибке. Уж очень там лимит зверский стоит.
В линухе, если используются потоки, то каждый поток по умолчанию
получает 10 MB стека.
Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем
более, что в форточках 1) процесс обычно имеет 2 GB адресного
пространства, а не 3, как в линухе 2) в форточках потоками принято
пользоваться активно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Конечно, это можно и сейчас сделать, вынеся код в отдельную функцию и вызывая его в первый раз из конструктора, а потом просто так. Но ИМХО это было бы логичнее. Т.е. я пересоздаю объект без перевыделения памяти.
Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Я думаю, потому, что это нарушит ссылочную целостность. У нас уже есть ссылки в других объектах на этот объект. И эти другие объекты будут крайне удивлены внезапной смерти того объекта и возникновению нового. У меня сейчас сильнейшее дежа вю, т.к. данная тема уже точно поднималась.
Не совсем так. Объект никуда не исчезнет, он просто переинициализируется. В конце концов мог бы он себя переинициализировать так
C c = new C(...);
// use
c.prop1 = ...;
c.prop2 = ...;
// etc.
а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.
S>Выделение памяти в управляемой среде — сверхестественно дешевая операция, сравнимая со стоимостью выделения памяти на стеке в C++. Не там воду ищешь.
Выделение — да. Но не сжатие кучи. А вот там сжимать пришлось бы меньше. Представь себе. что тебе нужно по ходу действия создать десяток кистей. Сейчас для каждой new, потом их всех уберет GC. В моем варианте new будет один, так что и ему придется лишь один объект убрать.
S>Для тех редчайших случаев, когда действительно дешевле переинициализировать объект, чем создавать новый, можно пользоваться двухстадийной инициализацией.
S>
S>Brush br = new Brush(Color(0,0,255));
S>br.Init(Color(0,0,255));
S>
Согласен, конечно. Но с конструктором было бы элегантнее.
PD>а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.
Павел, откровенно говоря, я лично не понимаю смысла в такой "оптимизации".
Ок, пусть у вас есть объект. У него 20 внутренних полей. Вы переаллоцируете основной объект, сохраняя для него изначальную ссылку. Но при этом все эти 20 внутренних полей устанавливаются в изначальное значение (ссылки меняются).
По сути — из 21 объекта вы меняете ссылки не 21 объекту, а 20. Вот такая вот "оптимизация"
...Ei incumbit probatio, qui dicit, non qui negat...
IT>Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?
да вот мне тоже кажется, что GC за себя всегда постоять сможет. Разберется он когда кому память выделять и без помощи программистов, думающих что их объекты самые тяжелые на свете
...Ei incumbit probatio, qui dicit, non qui negat...
N>во-первых само наличие финалайзера это кривые руки программера, таких классов очень мало (по крайней мере в Жабе, думаю 1/10000), и для них просто оптимизация запрещена.
это не кривые руки программера, а производственная необходимость. Количество классов тут ни при чем.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, vitaly_spb, Вы писали:
_>это не кривые руки программера, а производственная необходимость. Количество классов тут ни при чем.
да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ.
в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?
Здравствуйте, Pavel Dvorkin, Вы писали:
>Более того, ИМХО это вообще верно — чтобы качественно программировать на уровне N, надо понимать, что делается на уровне N-1. Уметь самому программировать на уровне N-1 не обязательно.
vitaly_spb,
> ПК>Что характерно, зачастую -- задолго до. > > ну да, я к тому что это не из-за кривых программистских рук просто есть обстоятельства, которые программисту не обойти
А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, c-smile, Вы писали:
CS>>Т.е. она идеологически правильная но практически не работает — тормозит.
IT>Графика в .NET тормозит не по причине GC, а по пречине того, что она базируется на GDI+.
Наверное.
Такое впечатление что GDI+ была сделана врагами специально чтобы .NET не разгонялась...
Здравствуйте, n0name2, Вы писали:
N>да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ.
В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.
N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?
Не знаю. Смахивает на неудачную попытку изобразить дестркуторы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, c-smile, Вы писали:
IT>>Графика в .NET тормозит не по причине GC, а по пречине того, что она базируется на GDI+.
CS>Наверное. CS>Такое впечатление что GDI+ была сделана врагами специально чтобы .NET не разгонялась...
Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
IT,
> N>да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ. > > В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.
Но на время отдельных фаз (в зависимости от режима) GC все потоки приостанавливаются, и Finalize определенно замедляет GC.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, reductor, Вы писали:
R>>В окамле это давно работает
IT>Работает или есть и иногда при очень удачном стечении обстоятельств используется? Сдаётся мне, что там столько НО!, что в реальном коде это почти не может быть использовано.
Разумеется, все не ограничивается простым утверждением "все локальные значения кидаем на стек"
Но для большого количества типов и ситуций это справедливо. В окамле жесткая система типов и правила игры.
В случае с Java конечно дело осложняется рефлексией и кучей всего другого, для чего потребуется более обширный статический анализ, но вариантов, когда, например, мы можем безбоязненно не дергать хип-аллокатор остается приличное количество.
Я, кстати, кажется, даже видел какие-то работы автора окамла (Ксавье Лерой) по верификации java-байткода.
Лень сейчас смотреть, но может статься, это даже связано с.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не совсем так. Объект никуда не исчезнет, он просто переинициализируется. В конце концов мог бы он себя переинициализировать так
PD>C c = new C(...); PD>// use PD>c.prop1 = ...; PD>c.prop2 = ...; PD>// etc.
PD>а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.
Ну, для immutable объектов такое непозволительно. Вот, скажем, если у нас есть строка, то ее нельзя "переинициализировать", т.к. ссылающийся на нее код полагается на ее принципиальную неизменность. Таких объектов довольно много — например, System.Drawing.Font.
S>>Выделение памяти в управляемой среде — сверхестественно дешевая операция, сравнимая со стоимостью выделения памяти на стеке в C++. Не там воду ищешь.
PD>Выделение — да. Но не сжатие кучи. А вот там сжимать пришлось бы меньше. Представь себе. что тебе нужно по ходу действия создать десяток кистей. Сейчас для каждой new, потом их всех уберет GC. В моем варианте new будет один, так что и ему придется лишь один объект убрать.
Гм. Павел, быстродействие GC в первом приближении зависит не от количества умерших объектов, а от количества живых. Если об этом помнить, то все встанет на свои места.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote:
> В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой > фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я > конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, > но черт возьми — /зачем/? А в обычных случаях рекурсии (типа обхода > дерева) такие глубины на практике недостижимы.
CS>При этом анализатор агрегата будет анализировать, думатель... — у ей внутре ведь есть, кажется, думатель? — ...думатель будет думать, и таким образом агрегат станет у вас обучаться. Вы и ахнуть не успеете, как он у вас начнет сам печатать
Вот-вот, великая тройка: MS, GC и .NET
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Sinclair, Вы писали:
S>В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем?
А пофик.
Ты прикинь, сколько это будет — 1024-е число Фибоначчи. И зачем их вообще вычислять? Реально этих чисел используется — всего-навсего сотня, ну две.
Я, конечно, понимаю, что пример абстрактный, просто так, к слову.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
n0name2,
>>> Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь? > > ПК>Что характерно, зачастую -- задолго до. > > если это сервер, то поняимя "закрыть приложение" не существует
+1.
> try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов.
-1. using in C#, RAII in C++.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Sinclair wrote: > > Pzz>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем > Pzz>более, что в форточках 1) процесс обычно имеет 2 GB адресного > Pzz>пространства, а не 3, как в линухе 2) в форточках потоками принято > Pzz>пользоваться активно. > В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой > фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я > конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но > черт возьми — /зачем/? А в обычных случаях рекурсии (типа обхода дерева) > такие глубины на практике недостижимы.
Это если считать, что программисты — люди разумные. Однако бывают и
такие, которые на стеке большие буфера заводят...
Cyberax wrote: > >> В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой >> фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я >> конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, >> но черт возьми — /зачем/? А в обычных случаях рекурсии (типа обхода >> дерева) такие глубины на практике недостижимы. > > Кстати, стек еще и расти сам умеет.
Это если ему есть куда. В однопоточной программе места, куда ему расти,
обычно хоть попой ешь. Но вот в многопоточной программе расти ему
предстоит только до следующего стека (до стека другого потока). А дотуда
может быть не так уж и далеко.
Здравствуйте, vitaly_spb, Вы писали:
_>Павел, откровенно говоря, я лично не понимаю смысла в такой "оптимизации".
_>Ок, пусть у вас есть объект. У него 20 внутренних полей. Вы переаллоцируете основной объект
Нет. Не переаллоцирцем объект. Оставляем его на месте и переделываем ему поля.
>сохраняя для него изначальную ссылку. Но при этом все эти 20 внутренних полей устанавливаются в изначальное значение (ссылки меняются).
_>По сути — из 21 объекта вы меняете ссылки не 21 объекту, а 20. Вот такая вот "оптимизация"
Это сильно зависит от того, что там в объекте
class A
{
int first;
bool second;
double third;
// etc
B b;
}
Здесь только одна ссылка (b) и три поля, которые не есть ссылки. Так что в этом случае будет 1 из 2.
А таких маленьких классов много. Посмотри изначальный постинг, там речь шла о классах кистей (туда же и перья и т.д.)
У SolidBrush, к примеру, всего 3 поля, если верить Reflector
System.Drawing.Brush.nativeBrush : IntPtr
System.Drawing.SolidBrush.color : Color
System.Drawing.SolidBrush.immutable : Boolean
Здравствуйте, Sinclair, Вы писали:
PD>>Выделение — да. Но не сжатие кучи. А вот там сжимать пришлось бы меньше. Представь себе. что тебе нужно по ходу действия создать десяток кистей. Сейчас для каждой new, потом их всех уберет GC. В моем варианте new будет один, так что и ему придется лишь один объект убрать. S>Гм. Павел, быстродействие GC в первом приближении зависит не от количества умерших объектов, а от количества живых. Если об этом помнить, то все встанет на свои места.
Антон, ИМХО во втором приближении быстродействие GC зависит от того, сколько памяти ему придется переслать, сжимая кучу. Насколько я понимаю, он при этом не занимается интеллектуальным заполнением дыр (т.е. поиском объектов, которые аккуратно в эту дырку уложились бы), а просто сжимает все к началу. А при этом чем меньше дыр, тем лучше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Антон, ИМХО во втором приближении быстродействие GC зависит от того, сколько памяти ему придется переслать, сжимая кучу. Насколько я понимаю, он при этом не занимается интеллектуальным заполнением дыр (т.е. поиском объектов, которые аккуратно в эту дырку уложились бы), а просто сжимает все к началу. А при этом чем меньше дыр, тем лучше.
Сжиманием кучи ГЦ в .NET занимается тотлько при сборке 2ого поколения. При сборке 0ого и 1ого поколений происходит копирование выжевших объектов в болие старшие поколение.
Те скорость работы зависит только от того сколько объектов выжило.
А сборка 2ого поколения производится очень редко.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Сжиманием кучи ГЦ в .NET занимается тотлько при сборке 2ого поколения. При сборке 0ого и 1ого поколений происходит копирование выжевших объектов в болие старшие поколение. WH>Те скорость работы зависит только от того сколько объектов выжило. WH>А сборка 2ого поколения производится очень редко.
Так, это значит, что я что-то не так понимаю. Посмотрю вечером Рихтера.
WH>Сжиманием кучи ГЦ в .NET занимается тотлько при сборке 2ого поколения. При сборке 0ого и 1ого поколений происходит копирование выжевших объектов в болие старшие поколение. WH>Те скорость работы зависит только от того сколько объектов выжило. WH>А сборка 2ого поколения производится очень редко.
Из Рихтера (картинки опускаю)
When the CLR initializes, it selects a threshold size for generation 0, say, 256 KB. (The
exact size is subject to change.) So if allocating a new object causes generation 0 to surpass
its threshold, a garbage collection must start. Let’s say that objects A through E occupy 256
KB. When object F is allocated, a garbage collection must start. The garbage collector will
determine that objects C and E are garbage and will compact object D so that it is adjacent
to object B. The objects that survive the garbage collection (objects A, B, and D) are said to
be in generation 1. Objects in generation 1 have been examined by the garbage collector
once. The heap now looks like Figure 19-8.
Итак, произошла сборка мусора в 0 поколении. Все выжившие объекты были сдвинуты в памяти, дабы заткнуть дыры.
И далее там же
When the application attempts to allocate object T, generation 0 is full and a garbage
collection must start. This time, however, the garbage collector sees that the objects in
generation 1 are occupying so much memory that generation 1’s 2-MB threshold has been
reached. Over the several generation 0 collections, it’s likely that a number of objects in
generation 1 have become unreachable (as in our example). So this time, the garbage
collector decides to examine all the objects in generation 1 and generation 0. After both
generations have been garbage collected, the heap now looks like Figure 19-14.
На рисунке показана куча, в которой произошло сжатие для поколений 0 и 1.
Так что твое "копирование выжевших объектов в болие старшие поколение" и есть их перемещение в памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
PD>Итак, произошла сборка мусора в 0 поколении. Все выжившие объекты были сдвинуты в памяти, дабы заткнуть дыры.
Нет. Они были перенесены в совсем другую область памяти.
PD>When the application attempts to allocate object T, generation 0 is full and a garbage PD>collection must start. This time, however, the garbage collector sees that the objects in PD>generation 1 are occupying so much memory that generation 1’s 2-MB threshold has been PD>reached. Over the several generation 0 collections, it’s likely that a number of objects in PD>generation 1 have become unreachable (as in our example). So this time, the garbage PD>collector decides to examine all the objects in generation 1 and generation 0. After both PD>generations have been garbage collected, the heap now looks like Figure 19-14.
PD>На рисунке показана куча, в которой произошло сжатие для поколений 0 и 1.
PD>Так что твое "копирование выжевших объектов в болие старшие поколение" и есть их перемещение в памяти.
Я надеюсь, ты не считаешь, что сложность перемещения в памяти как-то связана с расстоянием?
Все абсолтно верно. Если мы в цикле делаем Brush b = new Brush(), то при достижении порога GC обнаружит ровно 1 живой Brush. Именно он и будет передвинут в поколение 1. Область, ранее занятая миллионами мертвых Brush будет просто объявлена пустой (за O(1)) и в ней будет выделен новый Brush(), который мы запросили. Количество мертвых объектов при этом не влияет вообще ни на что.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, vitaly_spb, Вы писали:
_>>То есть ты по 100-бальной шкале вес объекта готов оценить? Мне кажется, GC это может сделать не хуже.
MS>Читай внимательнее. GC не может этого сделать в принципе, поскольку он знает только о managed ресурсах, объем которых близок к нулю. А вот что там кроется в unmanaged — он не знает и знать не может. И нет никакой возможности передать ему это знание.
Заведи глобальный счетчик дорогих объектов. Как только этот счетчик превысит некоторое пороговое значения -- вызывай GC (в конструкторе класса).
Здравствуйте, Sinclair, Вы писали:
PD>>Итак, произошла сборка мусора в 0 поколении. Все выжившие объекты были сдвинуты в памяти, дабы заткнуть дыры. S>Нет. Они были перенесены в совсем другую область памяти.
Ну тогда я не знаю, кому верить — тебе или Рихтеру. Он там картинки рисует и ясно показывает, что куда перемещается. Ни о каких совсем других областях памяти там и речи нет. Или это относится к 1.x, а в 2.0 иначе ?
S>Я надеюсь, ты не считаешь, что сложность перемещения в памяти как-то связана с расстоянием?
S>Все абсолтно верно. Если мы в цикле делаем Brush b = new Brush(), то при достижении порога GC обнаружит ровно 1 живой Brush. Именно он и будет передвинут в поколение 1. Область, ранее занятая миллионами мертвых Brush будет просто объявлена пустой (за O(1)) и в ней будет выделен новый Brush(), который мы запросили. Количество мертвых объектов при этом не влияет вообще ни на что.
Не совсем так. В этом примере да. А вот если у тебя будут
ЖМЖМЖМЖМ...
т.е живой, за ним мертвый, опять живой и т.д, т.е 500 тыс живых, а между ними по одному мертвому (я утрирую, конечно, но ты же сам миллион задал , то сжатие сведется к 500,000 пересылкам небольших объектов. А это цикл над rep movs, и он будет работать ИМХО намного медленнее, чем один rep movs непрерывного блока суммарного размера всех живых. Впрочем, последнее только ИМХО, про rep scasd я не забыл
Здравствуйте, IT, Вы писали:
IT>Системные ресурсы да, а всяческие доморощенные?
это какие??
N>>try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов. IT>Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.
PD>Нет. Не переаллоцирцем объект. Оставляем его на месте и переделываем ему поля.
Да, сорри, неправильно выразился
PD>Это сильно зависит от того, что там в объекте
Да, бесспорно.
PD>class A PD>{ PD> int first; PD> bool second; PD> double third; PD> // etc PD> B b; PD>}
PD>Здесь только одна ссылка (b) и три поля, которые не есть ссылки. Так что в этом случае будет 1 из 2.
Ну здесь конкретно вы экономите 1 переаллокацию (в данном случае вроде я то говорю?) — основного объекта. Это не много.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Для обучения — сразу не надо. Но все же программист на С++ должен понимать. что там ниже делается. Более того, ИМХО это вообще верно — чтобы качественно программировать на уровне N, надо понимать, что делается на уровне N-1. Уметь самому программировать на уровне N-1 не обязательно.
Я бы сказал так. Если технология спроектирована хорошо, то нание уровня N-1 не обязательно. Хотя обычно оно бывает полезно. В общем, N-1 — это скорее знания для экспертов, ну, или для продвинутых программистов. И то при условии, что это N-1 не начинает владеть мыслью программиста и определять проектные решения. А как показывает практика не все кто залез на N-1 могут адекватно оценить происходящиее.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, WolfHound, Вы писали:
WH>> public static void AddMemoryPressure(long bytesAllocated);
MS>Спасибо, но это не совсем то. Оно глобальное и работает только с памятью. А прочие ресурсы?
А у тебя память локальная что ли? Ты этим методом информирушь GC о том, что с неким управляемым объектом ассоциировано море неуправляемой памяти. Тот учитывает эту информацию в своих табличках, и далее вызовет GC по раньше, а то и попросту попытается проследить за твоим объектом в первую очередь (не дожидаясь сборки мусора).
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Как можно говорить об эффективности если все вспомогательные объекты удаляются сместе с Graphics?
Да, вот так и можно. Понимаешь, ли отрисовка — это почти вечность по сравнению с временим их создания и уничтожения. Компьютеры то стали отнюдь не детскими игрушками. Вот если пересоздавать те же шрифты при отрисовке каждой ячейке в гриде, то без проблем можно нарваться на тормоза и на современных компьютерах. Но это как правило в сотни, а то и тысячи раз большие потери нежели уничтожение кэша после отрисовки.
Зато экономятся память и ресурсы.
Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?
ЗЫ
Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению. Ты вчитывался в код который привел c-smile? Погляди внимательно на фрагменты вроде:
Заметь. Ни о каком кэшировании c-smile не заикался. Сталобыть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению стрых. Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
Тут дело в том, что ты ячно плохо понимашь как работает ЖЦ. ЖЦ не следит за одним объектом. Он следить на всем хипом. И если ЖЦ посчитает, что нужно очистить нулевое поколение (что обычно происходит и так очень часто), то никто не помещает ему это сделать.
Ты же можешь помочь ЖЦ ускорить сборку мусора указав, что твоей объект удерживает кучу анменеджед-памяти (функцией GC.AddMemoryPressure() от которой ты так пытаешся отпахаться).
К тому же ЖЦ включается если системе начинает нехватать памяти.
Так что единственное что тебе нужно сделать — это не держать жестких ссылок на объекты удерживающие неуправляемую память.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, n0name2, Вы писали:
N>>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями... WH>Только тут надо иметь в виду что стек не резиновый...
Дык они ведь не идеоты. Выделение больших массивов в стеке ко всему прочему снизит эффективность. Ведь весь кайф стэка в том, что он почти все время лежит в кэше процессора. А многокилобайтные массивы быстро свидут на нет это приемущество.
Скорее всего они будут применять некоторые эвристики типа размещаем на стеке только отдельные объекты не и массивы малого размера.
Ну, и не забывай, что в управляемой среде нет проблем с перемещением стека в другой сегмент памяти. Ведь все ссылки можно перестроить! Занимаем, если что, стэк в 10 метров, переносим содержимое старого в него, а старый грохаем. Лафа, блин! Но только если все на 100% управляемое. Один неуправляемый стэковый фрэйм и каюк. А в дотнете это явление очень частое. Так что возможно тут у Явы будет даже приемущество. Хотя опять же JNI приводит к такому же приплызду.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
N>>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать. WH>Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException. WH>Вобщем тут не все так однозначно.
Ну, ты их за лохов то не держи. Рекурсия будет первым признаком того, что ничего больше 10 байт на стэк помещать не надо.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Я подозреваю, что в современном мире вызвать StackOverflowException можно только по ошибке. Уж очень там лимит зверский стоит.
Лично наблюдал, как один орел добился рабочего SOE. Правда при этом это был КОМ-объект запускавшийся под управлением MMC-консоли в которой почему-то был подозрительно маленький стэк. Добился он этого как раз размещая на стэке большие массивы больших объектов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pzz, Вы писали: Pzz>>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем Pzz>>более, что в форточках 1) процесс обычно имеет 2 GB адресного Pzz>>пространства, а не 3, как в линухе 2) в форточках потоками принято Pzz>>пользоваться активно. S>В винде вроде бы мегабайт.
Зависит от настроек линкера для С++. Дотнет же волен делать что хочешь. Даже есть перегруженные конструкторы у Thread вроде:
public Thread(ParameterizedThreadStart start, int maxStackSize);
S> Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем? А в обычных случаях рекурсии (типа обхода дерева) такие глубины на практике недостижимы.
Ну, вот быстрая сортировка в вырожденых случаях дает, например.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Это если ему есть куда. В однопоточной программе места, куда ему расти, Pzz>обычно хоть попой ешь. Но вот в многопоточной программе расти ему Pzz>предстоит только до следующего стека (до стека другого потока). А дотуда Pzz>может быть не так уж и далеко.
А, кстати, что мешает в один прекрасный момент поглядеть, что стэка мало... вставить некую процедуру-заглушку и создать новый стэк? Эта заглушка будет первой функцией в новом стэке. Как только ей передадут управление она востановит указатель стека на старый стек и все дела.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.
Думаю, наличие финалайзера будет первым признаком того что объект обязан жить в хипе. Там еще целая куча эвристик будет. Просто уверен, что джит и ЖЦ окажутся в этом вопросе куда прозорливее чем 99% программистов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?
Финалайзеры конечно зло. Но без и ни файлик в ОС не отроешь, и подключение к БД можно проворонить.
Так что самостоятельно их конечно и в дотнете никто особо не клепает, но использовать переодически приходится. Вот только в дотнете они ничего не останавливают. Они вызваются в отдельном потоке.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, IT, Вы писали:
IT>>В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.
N>даже если бы это было полностью верно, никто не гарантирует что, скажем, незакрытый File подберется в течении ближайших суток (если он вдруг успел запромоутится в permanent generation). ЖЦ это только средство управления памятью а не системными ресурсами. не надо его юзать для того, для чего он не предназначен изначально.
Ну, суток, конечно карантировано. Если только вообще в приложении ничего не делать. Другое дело, что файл такой ресурс, что и пары минут может оказаться достаточным чтобы кто-то нарвался на его блокировку (например, тот же поток). Так что файлы нужно пасти акуратнее.
Но файл ресурс довольно особенный. С другими таких проблем обычно не бывает. Так потеря битмапа — это для NT фактически поретя занимаемой им памяти. Точно так же потеря соеденения с БД из пула не является проблемой. Когда соеденения закончатся можно собрать мусор и получить все потери обратно.
Так что не так уж бесполезны финализаторы. И уж точно они не вредны если не начинать строить логику на финализаторах. В общем, конечно лучше незабывать освобождать ресурсы вручную. Тому особо способствуют конструкции вроде using-а. Но финализаторы это та страховка которая позволит в большинстве случаев приложению работать, а не вылетать при малейшей ошибке.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>В окамле это давно работает R>Посколько внутри камл-программы мы вообще не видим никакого стека, ни регистров ничего такого, то компилятор этим нагло пользуется и раскидывает данные так, как ему удобно R>за 15 лет ничего не сломалось R>да не только окамл, большинство ML-компиляторов, Clean и Haskell так делают R>теперь вот до Жабы на третьи сутки дошло
О! Вот и функциональщики подтянулись.
ЗЫ
Только не оверквоть, плиз.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Работает или есть и иногда при очень удачном стечении обстоятельств используется? Сдаётся мне, что там столько НО!, что в реальном коде это почти не может быть использовано.
ИТ, странно от тебя слышать такие догмы.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот быстрая сортировка в вырожденых случаях дает, например.
Напоминаю, что переполнение стэка дает только тупо написанная сортировка. В этом случае да, глубина стэка — O(N). Исправляется очень просто — рекурсивно вызываем функцию сначала для большего подмассива, потом — для меньшего (по размеру). В этом случае гарантируется глубина вызовов не более O(log N), что можно считать эквивалентным гарантии "непереполнения". Наихудшее время остается O(N^2).
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>А у тебя память локальная что ли? Ты этим методом информирушь GC о том, что с неким управляемым объектом ассоциировано море неуправляемой памяти. Тот учитывает эту информацию в своих табличках, и далее вызовет GC по раньше, а то и попросту попытается проследить за твоим объектом в первую очередь (не дожидаясь сборки мусора).
Что-то я не понял. В каком именно месте происходит "ассоциация моря неуправляемой памяти" с объектом?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Зато экономятся память и ресурсы.
Это как? Вотм не нужно 3 кисти, 5 шрифтов чтобы рисовать. Ты предлагаешь создавать из каждый раз до рисования и удалять после, а я говорю что хранить их самими по себе (даже общими для всех контролов программы) куда лучше. То есть если у тебя 10 кнопок рувуют свой текст шрифтов arial Regualr 10pt, то ты на каждое рисование будешь создавать 10 объектов и удалять, а у меня будет всего один пока существует хоть что-то оспользующее этот шрифт. Это не просто хеш, это ещё и Reference counting.
VD>Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?
OK, давай вот цифирками кидаться. Я всё делал на Си++ (Даже фактически на Си) для того чтобы исключить возможность влияния GC и прочих сторониих факторов. Время измерял функцией QueryPerfomanceCounter.
Всё это отняло какую-то секунду. Сущий пустяк. Казалось бы ты прав... Нет,такого я мог допустить.
Потом я подумал, что неизвестно как хранятся объекты и возможно время создания и удаления объекта зависит от количества уже существующих. новый код выглядел так
И выполнялся уже 1.5 секунды. Потом я подумал, что, возможно, объекты инициализируются отложено и если их не использовать, то кое-что может так и не инициализироваться. В особенности я подозревал в этом шрифты. Пришлось уже создать окно Теперь уже тесты выглядели так
Получилось 11 и 10 секунд соответсвенно. Выходит ты прав? Ну я всё таки оставлю себе лазейку Всё что я измерял верно для Windows XP (SP2 если это важно) и GDI. Как обстоят дела в 98, 2000 и GDI+ вопрос отдельный. В целом, если мы говорим о GDI, то ты прав — ресурсы GDI довольно легкие в том смысле, что они довольно быстро создаются и удаляются.
VD>Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению.
Завидуешь? Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение.
VD>Ты вчитывался в код который привел c-smile? Погляди внимательно на фрагменты вроде: VD>
VD>Заметь. Ни о каком кэшировании c-smile не заикался.
Из интерфейса нельзя сделать вывод что кеширования нет.
VD>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.
Не знаю как ты, а я ознакомлялся тем что пишет c-smile и я не думая что он там поступил бы. Кроме того напомню, для того чтобы делать подобные выводы слишком мало информации.
VD>Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
Влад, у тебя мания преследования? Я просто увидел то, что мне не понравилось ответил и забыл. Если бы не твой сообщение я бы про тебя и не вспомнил.
Я вот легкостью признал, что ты прав, а тебе везде заговоры мерещатся. Будь проще и люди к тебе потянутся
Здравствуйте, n0name2, Вы писали:
IT>>Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.
N>да ну? и чемже? отсутствием checked exceptions?
Ну Влад уже как бы всё сказал, остаётся только добавить, что он поскромничал и привёл не самый кошмарный пример try/finally. Вот если я сейчас тут начну рисовать вложенности этих самых try/finally, вот тогда веселуха и начнётся.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, McSeem2, Вы писали:
MS>Что-то я не понял. В каком именно месте происходит "ассоциация моря неуправляемой памяти" с объектом?
С объектом я погорячисля. Ассоциируется конечно не с объектом, а с поколением. ЖЦ ведь по барабану что там за объекты. Ему важно рассчитать когда собрать мусор. Если ты зацепил море памяти, то нудно только сказать об этом ЖЦ и он сдвинет сборку на более ранее время.
Тут ведь как. Если ты хранишь сильную ссылку на объект и она переживет сборку первого поколения, то твой объект уедет во второе поколение и будет жить там довольно долго. Только нехватка памяти в системе заставит ЖЦ собрать второе поколение быстрее. Но первое и второе можно очень даже подтолкнуть. И эта функция как раз это и делает. Ну, как я понимаю.
Здравствуйте, adontz, Вы писали:
A>Это как? Вотм не нужно 3 кисти, 5 шрифтов чтобы рисовать. Ты предлагаешь создавать из каждый раз до рисования и удалять после, а я говорю что хранить их самими по себе (даже общими для всех контролов программы) куда лучше.
3 и 5 это вообще не цифры. А вот 40 уже цифры. Причем не смертельные по скорости, но ощутимые по памяти.
A> То есть если у тебя 10 кнопок рувуют свой текст шрифтов arial Regualr 10pt, то ты на каждое рисование будешь создавать 10 объектов и удалять, а у меня будет всего один пока существует хоть что-то оспользующее этот шрифт. Это не просто хеш, это ещё и Reference counting.
Понимашь, ли для кнопок можно вообще ничего не кэшировать. У них основное место простой закраской заполняется. Они и н GDI+ влет рисуются. Я виду речь о немного более сложных контролах вроде гридов и текстовых редакторов (мне именно они были интересны). Площади поверхности у них относительно большие и закраска разнообразная. Вот на них мой подход очень неплохо себя показывает.
Но кэшировать можно и более глобально. В конце концов можно заводить один графикс на форму или еще что придумать.
Еще раз повторяю, что подход c-smile-а — это вообще создание всех ресурсов на один раз. И все чтобы сэкономить по 8 байт на объект (не создавать его в хипе).
VD>>Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?
A>OK, давай вот цифирками кидаться.
A>Получилось 11 и 10 секунд соответсвенно. Выходит ты прав? Ну я всё таки оставлю себе лазейку Всё что я измерял верно для Windows XP (SP2 если это важно) и GDI. Как обстоят дела в 98, 2000 и GDI+ вопрос отдельный.
От ОС зависит тут мало. 98-е я уже 5 лет не видел и видеть не хочу. А вот от режима сглаживания шрифтов скорость отрисовки зависит сильно. Но включить его можно только на ХРюше. Так что 2000-ые можешь рассматривать как ХР без сглаживания, т.е. на ней быстрее.
A>В целом, если мы говорим о GDI, то ты прав — ресурсы GDI довольно легкие в том смысле, что они довольно быстро создаются и удаляются.
Все не так просто. Как видишь создание всего этого дела 1000 раз удовольствие дорогое. Все же отрисовка должна уложиться хотя бы в 0.4 сек. А лучше в 0.01. Но при среденей отрисовке создается пара шрифтов и пара браше. Ну, даже там десяток. Это роли не ирает. А вот тормоза начинаются когда ты создашь, например, для каждой ячейки грида по шрифту и кисти. Вот тут наступает полный приплызд. И тут кэширование в неком Графиксе получается очень красивым решением. Код по прежнеме работает с объектами. Мы может даже наследовать их друг от друга. Ну, там перо от кисти, нисть еще от чего... Можем хранить объекты типа шрифтов в ячейках. Стоить они будут минимум. Особенно это актуально для управляемого мира. Ну, а кэш нас спасает от создания тысяч шрифтов. В итоге мы получаем хороший контроль ресурсов, удобную ОО-модель, не заморачиваемся на С-шной модели предложенной c-smile-ом и приличную скорость. Что еще желать? Дальнейшая экономия бессмысленна.
VD>>Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению.
A>Завидуешь?
Нет. Логику хочу понять. Для меня странно столь алогичные действия даже несмотря на полное понимания причин этого.
A> Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение.
Ясно. Ну, тогда зашел бы чтоли в дотнет. Там эта тема месяц или два назад поднималась.
A>Из интерфейса нельзя сделать вывод что кеширования нет.
А ты подумай. Как он будет кэшировать и где? Ведь максимум так же как я. Но ты же был так бурно против моего предложения. Хотя по сути интерфейсно оно отличалось только тем, что предлагало все же не отказываться от объектов вообще, а всего лишь сделать объекты по легче, кэширую хэндлы в отдельном объекте. Кстати, объект можно было бы сделать и глобальным для потока запихнув в сред-статик-переменную... если уж на то пошло.
То есть речь шла по существу о "С-стиле vs. ОО-стиле".
VD>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.
A>Не знаю как ты, а я ознакомлялся тем что пишет c-smile и я не думая что он там поступил бы. Кроме того напомню, для того чтобы делать подобные выводы слишком мало информации.
Думаю, что кэшированием там и не пахло. Объекты, блин, экономил.
VD>>Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
A>Влад, у тебя мания преследования?
Я тебе уже второй раз говорю. Ага. Бегаю за тобой... преследую. Вот сейчас... ты тихо мирно предложил c-smile-у свою идею, а прибежал и неподумал влепил тебе минус. Смотрю на себя и удивляюс... маньяк да и только.
A> Я просто увидел то, что мне не понравилось ответил и забыл. Если бы не твой сообщение я бы про тебя и не вспомнил.
Ох я уж вижу как ты про меня не вспоминашь. Ну, разубеди мнея в моей мании. Покажи где ты еще кого-то так же дружески критиковал?
A>Я вот легкостью признал, что ты прав, а тебе везде заговоры мерещатся. Будь проще и люди к тебе потянутся
Я прост как три копейки. Что вижу о том и говорю. Заметь без какой-то задней злобы. Говорю тебе открыто. Перестань все время меня провцировать и будет у нас с тобой мир да любовь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ПК>>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
VD>Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.
VD>Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят. Так что наличие большого количества хэндлов автоматом приводит к сборки мусора с последующей финализацией повисших хэндлов.
VD>Как говорится: Если у вас параноя — это еще не означает, что за вами не следят.
VladD2,
> Пашь, во что на этот раз не веришь то? Колись.
Не не верю, а не согласен.
ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.
Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят.
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Все не так просто. Как видишь создание всего этого дела 1000 раз удовольствие дорогое.
Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду.
A>> Вообще-то я ставил три балла не за код, а за поднятие интересного, на мой взгляд, вопроса. Обрати внимание, что это не теоретические фантазии — человек много чего сделал, прежде чем сложить своё мнение. VD>Ясно. Ну, тогда зашел бы чтоли в дотнет. Там эта тема месяц или два назад поднималась.
Мне c-smale просто симпатичен Только сильно огорчайся, у тебя ещё не всё потеряно.
A>>Из интерфейса нельзя сделать вывод что кеширования нет.
VD>А ты подумай. Как он будет кэшировать и где? Ведь максимум так же как я.
Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще.
VD>То есть речь шла по существу о "С-стиле vs. ОО-стиле".
Не факт. Можно иметь объекты Brush в которых будет хранится описание кисти, но не систменый ресурс. А ресурс будет создаватся на лету объектом Graphics. Вот о чём говорим мы, а c-smile говорил вообще не об этом, а о накладности создания большого количества мелких объектов. Рисование было просто примером такого случая.
И дело не в большой любви к Си стилю, а в оптимизации. По сути время создания и удаления системного ресурса HBRUSH может быть сравнимо со временем выделения и освобождения памяти объекта Brush. Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо.
VD>>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.
Подожди ещё 37 секунд, а потом засчитай ему нокаут.
A>>Влад, у тебя мания преследования?
VD>Я тебе уже второй раз говорю. Ага. Бегаю за тобой... преследую. Вот сейчас... ты тихо мирно предложил c-smile-у свою идею, а прибежал и неподумал влепил тебе минус. Смотрю на себя и удивляюс... маньяк да и только.
Так ты на минус обиделся? Бедный мальчик. Ну ладно, я больше не буду.
VD>Перестань все время меня провцировать
Нда. Ну и аргументы пошли. Ещё посуду побей и расскажи что ты потратил на меня лучшие 10 лет своей жизни с 29 до 32 лет
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
ПК>
Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.
ПК>
Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят.
Так с сказал бы что-нибудь. Или ты как этот который несогласен с обоими...
Можешь обосновать мою неправоту? Глядишь что-то интересное получилось бы. А то по твоему минусу народ может подумать, буд-то со всеми остальными моими словами ты согласен.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VD>>Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.
IT>Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.
Да, нет. Видишь вот ПК улыбками изошелся. Понимает чем дело может обернуться.
На самом деле оптимизация мощьнейшая. Вопрос только в качестве ее реализации. Там анализ нужен нехилый ведь.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Меня бы вполне устроило, если бы можно было каким-то способом указать системе на дороговизну объекта. Но такого способа, насколько я понимаю, не существует.
ПК>Не уверен, насколько это работает, но многие рекламируют Safe Handles из .Net FW 2.0.
Сдается мне, что ты что-то путашь. Этот класс от перерасхода памяти не гарантирует.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления
Вообще-то можно вроде. Через битмап.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PD>1000 раз дергать кучу там, где можно и один раз не дергать — хорошая, кстати иллюстрация на тему микрооптимизации, за которую меня некоторые ругали . Вот таким невиинным кодом убивают производительность.
Интересно что ты скажешь когда через год на Яве первый вариант кода порвет твой вотрой на С++? Они тоже будут размещать данные на стеке, только у них вообще нет ни деструкторов, ни конструкторов и думать о том где буфер размещен не нужно.
Вот погляди, тут где-то на Окамле битмапчик рассчитвали. Окамл явно тоже связаннй список вместо того чтобы в ЖЦ создавать превратил в массив и бросил в стэк.
А все потому, что когда программист не может "помочь" компилятору, компилятор может сам думать как лучше.
На сегодня компиляторы делают человека по кодогенерации маш.кода для конкретных процессоров. А завтра начнут делать в вопросах размещения переменных в памяти. Просто для этого нужно как следует вложиться в компиляторы.
ЗЫ
Что до add esp... Такой глупости даже дотнетный джит не сделает. Память под переменные будет выделена еще перед циклом (в начале функции). Так что в цикле максимум будет вызван конструктор и деструктор. Если это структуры, то вообще ничего. Правда память при этом тоже не проинициализируется.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Все так, кроме как с потоками и ЖЦ. ЖЦ разные бывают. И так чтобы совсем без синхронизации невозможно в принципе. По хипу на поток так точно небывает. Бывает по хипу на процессор и по хипу на процесс. Но и там, и там будут блокировки. Не на мьютексах скорее всего. Но все же.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Вот именно. Фича может и отличная, но редкая. Примерно как динозавры в наше время.
VD>На самом деле оптимизация мощьнейшая. Вопрос только в качестве ее реализации. Там анализ нужен нехилый ведь.
Нужен. Но что-то у меня в голове большинство оптимизацй сводятся к отказу от размещения объекта в стеке. Если можешь приведи мне пример, когда это реально, чтобы сдвинуть мою приторможенную фантазию с места.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, adontz, Вы писали:
A>Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду.
Ошибашся. Ворд и Эксель живут обычно скромнее. 100 шрифтов на экране за раз — это уже зоопарк каой-то.
A>Мне c-smale просто симпатичен Только сильно огорчайся, у тебя ещё не всё потеряно.
A>Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще.
А может их тогда просто не уничтожать? Не, ну, процесс загроется и все грохнется само.
VD>>То есть речь шла по существу о "С-стиле vs. ОО-стиле".
A>Не факт. Можно иметь объекты Brush в которых будет хранится описание кисти, но не систменый ресурс.
Ты внимательно читал предоложение c-smile-а? Он как раз с объектами и борится объясняя что тормоза в них.
A> А ресурс будет создаватся на лету объектом Graphics. Вот о чём говорим мы, а c-smile говорил вообще не об этом, а о накладности создания большого количества мелких объектов. Рисование было просто примером такого случая.
Хорошим надо признаться примером. Сэкономил на создании ничего не стоящих объектов вроде описания шрифта и проиграл на времени создания ресурсов которых хоть и отностельно дешевы, но далего не бесплатны.
A>И дело не в большой любви к Си стилю, а в оптимизации. По сути время создания и удаления системного ресурса HBRUSH может быть сравнимо со временем выделения и освобождения памяти объекта Brush.
Еще одна ошибка. Попробуй ради хохмы создать тестовое приложение в котором посоздавать эти самые объекты без HBRUSH-ей. Опять удивишся. Это очень быстро. За время пока ты создавал 100 башей ты создашь 100 тысяч объектов того же объема.
A> Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо.
Я и говорю, что исходит из ложных предпосылок.
VD>>>>Стало быть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению старых.
A>Зависит от реализации.
Зависит, зависит. Но вот уж больно не просто будет делать кэширование в его варианте. А главное, что после этого надо сравнить сколько времени уходит на создание объеков-пустышек и понять, что боролся с ветрянными мельницами.
A>Подожди ещё 37 секунд, а потом засчитай ему нокаут.
ОК
A>Так ты на минус обиделся? Бедный мальчик. Ну ладно, я больше не буду.
Еще раз. Плевать мне на минус. Меня инересует обоснование.
A>Нда. Ну и аргументы пошли. Ещё посуду побей и расскажи что ты потратил на меня лучшие 10 лет своей жизни с 29 до 32 лет
Интересный подход. Надо будет запомнить.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления
VD>Вообще-то можно вроде. Через битмап.
Ну да. Ты смайлик что-ли забыл поставить?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, WolfHound, Вы писали:
WH>Сжиманием кучи ГЦ в .NET занимается тотлько при сборке 2ого поколения. При сборке 0ого и 1ого поколений происходит копирование выжевших объектов в болие старшие поколение.
Кстати, все еще интереснее. Если в эфимерном сегменте (первое и нулевое поколение) остается мало места, то прямо весь сегмент может быть переведен во второе поколение (со всеми объектами), а для эфимерного может быть выделена новая память. Так что иногда даже копирования не бывает.
WH>Те скорость работы зависит только от того сколько объектов выжило. WH>А сборка 2ого поколения производится очень редко.
+1
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Из Рихтера (картинки опускаю)
PD>When the CLR initializes, it selects a threshold size for generation 0, say, 256 KB. (The PD>exact size is subject to change.) So if allocating a new object causes generation 0 to surpass PD>its threshold, a garbage collection must start. Let’s say that objects A through E occupy 256 PD>KB. When object F is allocated, a garbage collection must start. The garbage collector will PD>determine that objects C and E are garbage and will compact object D so that it is adjacent PD>to object B. The objects that survive the garbage collection (objects A, B, and D) are said to PD>be in generation 1. Objects in generation 1 have been examined by the garbage collector PD>once. The heap now looks like Figure 19-8.
PD>Итак, произошла сборка мусора в 0 поколении. Все выжившие объекты были сдвинуты в памяти, дабы заткнуть дыры.
Чушь кстати, у него какая-то. Размер задется не для поколения, а для сегмента. Нулевое и первое поколение живут в одном сегменте. Во втором фрэймворке размер сегмента минимум 16 метров. Размер нулевого поколения стораются подбирать под размер кэша процессора. Тапа все что в нем делается, все быстро. Ну, и у меня реальный размер нулегвого поколения доходит до 1.5 метров.
PD>И далее там же
PD>Так что твое "копирование выжевших объектов в болие старшие поколение" и есть их перемещение в памяти.
Копирование несомненно означает перемещение в памяти. Только без перекрытия. Чистыйе ассемблерные команды. Но иногда весь сегмент переводится во второе поколение. При этом никакого копировани нет.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну тогда я не знаю, кому верить — тебе или Рихтеру. Он там картинки рисует и ясно показывает, что куда перемещается. Ни о каких совсем других областях памяти там и речи нет. Или это относится к 1.x, а в 2.0 иначе ?
Павел, поколения 0 и 1 находятся в одном сегменте виртуальной памяти. Второе поколение может находиться в любом количестве сегментов, но только не в том где находятся нулевое и первое. Вернее это так для 1.1. Во втором фрэймворке сегменты которые не заполнены могут переиспользоваться. Но все равно второе поколение всегда не пересекается с нулевым и первым. Сборка нулевого поколения всегда сдвигает объекты из нулевого поколения. Так что они точно уезжают из этого сегмента. А вот при сборке второго поколения все сложнее. Тут возможно перемещение внутри одного сегмента.
Ну, а так ли понял это Рихтер и правильно ли его понял ты это уже отдельный вопрос.
S>>Я надеюсь, ты не считаешь, что сложность перемещения в памяти как-то связана с расстоянием?
PD>
А кстати, зря. Все же в кэше память двигается куда быстрее.
PD>т.е живой, за ним мертвый, опять живой и т.д, т.е 500 тыс живых, а между ними по одному мертвому (я утрирую, конечно, но ты же сам миллион задал , то сжатие сведется к 500,000 пересылкам небольших объектов.
Оно и так к нему сведется. Только таких объемов в нулевом поколении почти не бывает. А о мертвых объектах ЖЦ вообще не подозревает. Для него это вообще пустая память.
PD> А это цикл над rep movs, и он будет работать ИМХО намного медленнее, чем один rep movs непрерывного блока суммарного размера всех живых. Впрочем, последнее только ИМХО, про rep scasd я не забыл
rep movs сейчас можно увидеть только в доисторическом CRT. В СLR для копирования памяти вроде как SSE2-инструкции используются. Ну, а коприрование по любому ведется пообъектно. Причем скорее всего куда более трудоемкая опрация не копирование объектов, а правка ссылок на объекты. Ведь после перемещения они все должны быть верными.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Я создавал 100 раз по 100 штук. У Word/Excel где-то по 200 объектов GDI. У VS ~800, так что 100 это вполне реальный ориентир. И один "комплект" создаётся на 1 миллисекунду. VD>Ошибашся. Ворд и Эксель живут обычно скромнее. 100 шрифтов на экране за раз — это уже зоопарк каой-то.
Я не сказал шртфтов, я сказал объектов GDI. Cмотрел из Task Manager.
A>>Можно в статической переменной/синглтоне. Тогда объект будет уникален не для Graphics, а для приложения вообще. VD>А может их тогда просто не уничтожать? Не, ну, процесс загроется и все грохнется само.
Нет, я ещё говорил о reference counting. Суть в том, что в каждый конкретный момент времени У нас есть всё что необходимо для отрисовки
Все объекты уникальны по параметрам (нету двух одинаковых объектов).
с одной стороны это легко реализуется именно в вОО среде, с другой как бы быстро не создавались GDI объекты, это всё таки системынй ресурс и чем их меншьше, тем в целом всем лучше жить.
A>> Ну в GC среде ещё может быть и переноса. А может и не быть сравнимо. Но вся разработка c-smile исходит из того что сравнимо. VD>Я и говорю, что исходит из ложных предпосылок.
У него Java. Компилятора у меня нет, да и язык я не знаю. Всё таки c-smile пишет прикладные программы, это не очередной оберонщик. Хорошо бы чтобы он какие-нибудь сравнение привёл.
С другой стороны, есть ещё непочатый край для тестов в виде Linux...
Здравствуйте, VladD2, Вы писали:
VD>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.
Очень похоже на оптимизацию по Дворкину.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
VD>А в setBrush что происходит? Куда девается кисть ассоциированная с контекстом в данный момент? Когда уничтожается эта кисть?
DeleteObject. Для brush/pen это дешевая операция. Для font нет.
VladD2 wrote:
> N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не > используются. зачем они нужны? > Финалайзеры конечно зло. Но без и ни файлик в ОС не отроешь, и > подключение к БД можно проворонить. > Так что самостоятельно их конечно и в дотнете никто особо не клепает, > но использовать переодически приходится. Вот только в дотнете они > ничего не останавливают. Они вызваются в отдельном потоке.
Останавливают — всю систему. Когда по какой-то причине финализаторы
блокируют поток финализации.
Здравствуйте, WolfHound, Вы писали:
WH>Нет еще хуже. Вот таким
... WH>Ибо в твоем варианте если reader.Close(); бросит исключение то writer.Close(); вызван не будет.
Ну, он вроде как исключений не генерирует.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
VD>>Дале можно только помечтать об устранении виртуальности вызово и продвижении тел анонимных методов внутрь функций принимающих их в качестве делегатов... В общем, Васюки отдыхают и это будет реализовано в ближайшие 5-10 лет. Главное дожить.
IT>Очень похоже на оптимизацию по Дворкину.
Разница между оптимизацией по Дворкину и оптимизацией джита заключается в том, что в одном случае он будет делать ее руками накосячив и сделав не то что нужно, а во втором случае это будет продуманная оптимизация джита. При этом она гарантированно не будет влиять на результаты вычисений.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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читано на эффективную работу.
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, 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?
В чем сермяжность?
Здравствуйте, 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>Здравствуйте, c-smile, Вы писали:
CS>>В .NET немного грустнее. Ибо требуется делать marshall/pin на каждом вызове да плюс CS>>еще напрягать предмет Владовой гордости — HandleCollector.
VD>1. Где я чем-то гордился?
Где-то там "выше и левее".
Я так понял что ты собираешься еще и свой написать — что-то там про HashTable и handles мелькало.
VD>2. Нет никаких пинов. Хэндл — это вэлью-тип хранящий некое число ассоциированное с ресурсом. Так что тут никакого оверхэда.
Да, наверное это так. Но все равно HandleCollector наличествует.
Кстати странный зверь этот HandleCollector.
Как я понимаю это банальный reference counter.
Что называется и в борьбе с зеленым змием побеждает змий.
Здравствуйте, McSeem2, Вы писали: MS>Тебя обманули, ООП заключается вовсе не в этом. Не спрашивай меня, в чем оно заключается, но могу сказать, что точно не в иерархиях классов.
Ну кстати, я считаю вот такие изовращения одной из причин внедрения полноценной управляемой среды. Если бы библиотека была чисто Managed, то стоимость создания карандаша была бы равна стоимости боксинга структуры Color, при возможности через 10 лет получить
а) технологию по штриховой закраске контуров вместе с ее поддержкой без изменения существующего кода
б) escape анализ и вынесение этих карандашиков в стек благодаря улучшению JIT компилятора. Дальше уже следует инлайнинг и прочие удовольствия, которые и приведут к целевому коду, эквивалентному прямому вызову SetPen.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Пул на то и нужен, чтобы время выделения ресурса стремилось к нулю.
и он это делает при условии своевременного возврата ресурсов. если возврат ресурсов чуть задержать то пулу придется все время рости и толку от него не будет никакого.
VD>Вот и в дотнете для соеденений он используется именно для этого. Лично я выделяю соеденения примерно так: VD>
int count = pool.query("select count(*) from abc where a = ?", 123, new ScalarHandler<Integer>());
а все незаслуженно нелюбимые дотнетчиками try/finally внутри спрятаны.
VD>Но даже если этого не сделать, а просто забывать ссылки, то при нехватке соеденений будет собран мусор и они все снова вернутся в пул соеденений.
когда будет возвращен? через минуту, день, месяц? это слишком (фатально) поздно если у тебя 100 запросов/сек. если он попал в перманент дженерэйшн а свободной памяти полно то в обозримом будующем можно на это не расчитывать.
Здравствуйте, VladD2, Вы писали:
VD>Ведь тут кроме модификации языка нужно еще приучать к этому делу отладчик, редактор, средства рефакторинга и т.п.
как раз это небольшая проблема. такого рода плагины к Eclipse/IDEA пишутся пачками.
VD>Однако пока что ее нет и лично ты долбишь try/finally своими ручками. И это не единственный паттернк который тебе придется долбить самому. Мни лично это делать не охота. Лучше уж иметь их встроенными в язык. Поэтому я предпочитаю Шарп.
ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>".
во-вторых, ты долбишь (ну хорошо — VS долбит)
namespace {
}
ручками в каждом! классе и почемуто тебя этот синтаксический оверхед не смущает (причем от него никуда не дется), хотя он намного более часто используется. в-третьих все наиболее частые паттерны в этом роде давно завернуты в библиотечные вызовы вроде
int count = pool.query("select count(*) from a", new ScalarHandler<Integer>());
в-четвертых ИМХО рассматривать "синтаксический оверхед" (весьма субъективный) как более-менее значительный критерий выбора платформы просто несерьезно.
VD>Но если появится нечто промышленного качества поддерживающее расширение синтаксиса, то я с удовольствием буду писать на этом чуде.
предположим что есть плагины к очень популярной IDE которые расширяют отладчик и т.п. для работы с Syntax Extender, и что — перейдешь на Жабу? (ради такого не лень будет потратить пару — тройку дней)
Здравствуйте, VladD2, Вы писали:
VD>>>Это если где-нить внизу не попадется неуправляемый стековый фрэйм.
ANS>>Хм. Интересный вопрос. Ситуация маловероятная, но всё же... Нужно уточнить.
VD>Что же это маловерятная? Пока ОС неуправляемая, ситуация эта очень даже возможна.
Для этого нужно чтобы вызов вышел из неуправляемой среды и вернулся назад. Имхо, в виду претензии управляемой среды на самодостаточность, чаще всё заканчивается на первом шаге.
Здравствуйте, McSeem2, Вы писали:
MS>Карандаш картинкой? Это явный гон. Никто такого не умеет делать, только я умею, да и то со значительными ограничениями.
public partial class Form1 : Form
{
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
e.Graphics.DrawEllipse(
new Pen(new TextureBrush(Properties.Resources.Image1), 10),
10, 10, 100, 200);
}
}
Еще вопросы?
MS> Нарисовать линию паттерном в виде произвольного битмапа, да еще и с фильтрацией — это не просто задача, это — мегазадача. Изобретение карандашей по сравнению с такой задачей — это детская песочница, не стоящая упоминания.
Незнаю как там с фильтрацией, а в GDI+ ресует.
MS>Тебя обманули, ООП заключается вовсе не в этом. Не спрашивай меня, в чем оно заключается, но могу сказать, что точно не в иерархиях классов.
Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, VladD2, Вы писали:
VD>>Ведь тут кроме модификации языка нужно еще приучать к этому делу отладчик, редактор, средства рефакторинга и т.п.
N>как раз это небольшая проблема. такого рода плагины к Eclipse/IDEA пишутся пачками.
Пачками говоришь? А можно вот поглядеть не не пачку, а на один плагин поддерживающий этот самый The Java Syntactic Extender. А то языком то конечно пачками, но я то прекрасно понимаю сложность данной задачи и мне не верится, что можно вот так просто решать такие сложные задачи.
N>ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>".
Доблить это образно. Все же код пишется куда реже чем читается. Так что кроме скорости ввода нужно еще и на прототу восприятия внимание обращать.
N>во-вторых, ты долбишь (ну хорошо — VS долбит)
N>
N>namespace {
N>}
N>
N>ручками в каждом!
Я ни разу не написал ни одного пространства имен вручную. Оно уже есть. Я только меняю имена на подходящие. К тому же это уже минимальная конструкция и встречается она один раз на класс/файл. А вот try/finally-ов может быть куда больше и это далеко не минимальная конструкция. Это паттерн который каждый раз нужно реализовывать вручную, а потом мысленно разбирать его в коде. Точно так же, кстати, было с foreach до недавнего времени. И ничего хорошего в этом нет. Согласен, что решение на базе чего-то вроде Syntactic Extender было бы идеальным. Но, как я уже говорил, его нужно довести до промышленного качества. Расширения должны автоматом поддерживаться рефакторингом, отладчиком и т.п.
N> классе и почемуто тебя этот синтаксический оверхед не смущает (причем от него никуда не дется), хотя он намного более часто используется. в-третьих все наиболее частые паттерны в этом роде давно завернуты в библиотечные вызовы вроде
Да не чаще он используется. И как ты правильно заметил от него никуда не деться. Да и уменьшить его уже не удастся без потери информации. А вот заменить try/finally using-ом можно легко. Причем это только увеличит объем информации (паттерн будет виден без мысленного распознования). Да и ошибиться будет куда сложнее.
N>
N>int count = pool.query("select count(*) from a", new ScalarHandler<Integer>());
N>
Это частный случай. От использования и управления ресурсами все равно никуда не деться.
N>в-четвертых ИМХО рассматривать "синтаксический оверхед" (весьма субъективный) как более-менее значительный критерий выбора платформы просто несерьезно.
Вообще-то мы говорим о языке. Ну, да если говорить о платформе, то лично мне в Яве не нравится в первую очередь не JVM, а именно язык. Нельзя сказать, что в нем мне не нравится только синтаксический оверхэд, но и он влияет на отношение. В купе с некоторым количеством неустраненных граблей и неудобным интеропом он действительно отталкивает от языка, и как следствие от платформы.
Я бы вообще поставил вопрос по другому. Я вижу только два приемущества в Яве перед дотнетом. 1. Она перенесена на намного большее количество платформ. 2. Для нее есть больше фрэймворков и серверов в области разработки корпроративного ПО.
VD>>Но если появится нечто промышленного качества поддерживающее расширение синтаксиса, то я с удовольствием буду писать на этом чуде.
N>предположим что есть плагины к очень популярной IDE которые расширяют отладчик и т.п. для работы с Syntax Extender, и что — перейдешь на Жабу?
А почему бы и нет?
N>(ради такого не лень будет потратить пару — тройку дней)
Тройку дней на что? Ты серьезно считашь, что написать плагин к ИДЕЕ полностью интегрирующий Syntactic Extender — это занятие на тройку дней? Ну, ты крут!
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>и он это делает при условии своевременного возврата ресурсов. если возврат ресурсов чуть задержать то пулу придется все время рости и толку от него не будет никакого.
Так. Давай еще раз проанализируем ситуацию.
Итак. У нас есть пул содержащий соеденения. Да, конечно, если мы будем брать из этого пула соеденения и помещать их в некие переменные (удерживать на них ссылки долгое время), то рано или поздно пул кончится и соеденения будут создаваться для каждого запроса (если вообще не получим исключение). Но ведь речь идет о том, что ссылки на соеденения попросту теряются. Объект на который нет ссылки считается мертвым объектом. Причем болшинство соеденений умирает еще в нулевом поколении. Да, до сборки мусора мы не узнаем о том, что соеденения уже не используются. Но ведь сборка мусора нулевого поколения и так происходит довольно часто (особенно в дотнете где используется 3 поколения). Стало быть большинство соеденений будут постоянно возвращаться обратно. Ну, а если соеденение проскочило таки в следующее поколение или пул израсходовался до сборки нулевого поколения, то увидев что пул пуст можно просто вызвать сборку мусора. Это вернет все не используемые соеденения в пул и мы сможем снова их использовать.
VD>>Вот и в дотнете для соеденений он используется именно для этого. Лично я выделяю соеденения примерно так: VD>>
N>int count = pool.query("select count(*) from abc where a = ?", 123, new ScalarHandler<Integer>());
N>
Это частный случай. Если запрос простой и еденеичный, то и в дотнете он выполняется похожим образом. Но ведь бывают случаи когда нужно выполнить несколько запросов на соеденении (например, водной транзации).
N>а все незаслуженно нелюбимые дотнетчиками try/finally внутри спрятаны.
В частном случае. Да и то при реализации этого query все равно прийдется писать эти try/finally. Так зачем мучаться?
N>когда будет возвращен? через минуту, день, месяц?
См. выше.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Причем болшинство соеденений умирает еще в нулевом поколении. Да, до сборки мусора мы не узнаем о том, что соеденения уже не используются. Но ведь сборка мусора нулевого поколения и так происходит довольно часто (особенно в дотнете где используется 3 поколения).
ок, как часто происходит сборка нулевого поколения? сколько раз в секунду? предположим что есть пул со 50ю соединениями и есть нагрузка от 10 до 200 запросов/сек (совершенна типичная ситуация для задач которые обычно решаются на Жабе). вот у нас настал пик и мы потеряли за 0.25с все 50 соединений. неужели сборка 0го поколения происходит настолько часто (у меня в приложениях это бывает ну раз в минуту примерно)? и если да то какова вероятность попадения соединения в 1е/2е поколенье?
я правильно понял что ты предлагаешь в реализацию пула встраивать механизм который ЗНАЕТ о существовании ЖЦ? это же жуть какая-то! тут кода/оверхеда будет на порядок больше чем от какого-то там try/finally. ну предположим что он дернет ЖЦ — мол собирай. а можно сказать какое именно поколенье нужно собирать или это вызовет полную сборку мусора и остановку всего приложения более чем на секунду что совершенно неприемлемо (в любом уважающем себя Жабном приложении полная сборка не происходит никогда, разве что пару раз на стартапе).
VD>Это частный случай. Если запрос простой и еденеичный, то и в дотнете он выполняется похожим образом. Но ведь бывают случаи когда нужно выполнить несколько запросов на соеденении (например, водной транзации).
а на этот случай есть вполне работоспособный PL/SQL (в отличае от мрачного T-SQL), причем на эту роскошь у заказчика часто деньги остаются — не надо платить МС за кучу лицензий.
кроме того, (хотя лично я и не люблю ОРМ) многие пользуются отличными продуктами для доступа к БД (Hibernate, JDO, EJB3, из которых для .НЕТ есть только альфа NHibernate) в виде объектов, там API уровнем намного выше.
VD>В частном случае. Да и то при реализации этого query все равно прийдется писать эти try/finally. Так зачем мучаться?
кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе.
Здравствуйте, VladD2, Вы писали:
N>>ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>". VD>Доблить это образно. Все же код пишется куда реже чем читается. Так что кроме скорости ввода нужно еще и на прототу восприятия внимание обращать.
ну как сказать простота восприятия — у try/finally есть свои приемущества с т.з. чтения кода — видно какой именно метод вызывается при закрытии ресурса. и не надо помнить что это Disposable класс и т.д.
VD>Я ни разу не написал ни одного пространства имен вручную. Оно уже есть. Я только меняю имена на подходящие. К тому же это уже минимальная конструкция и встречается она один раз на класс/файл. А вот try/finally-ов может быть куда больше и это далеко не минимальная конструкция. Это паттерн который каждый раз нужно реализовывать вручную, а потом мысленно разбирать его в коде.
так я тоже не пишу try вручную но у меня кол-во try/finally конструкций существенно меньше кол-ва файлов с исходным кодом. соот-но мустора от namespace больше чем от try/finally. и чтобы продратся через лишнюю пару curly braces от namespace у неподготовленного человека точно также уходят драгоценные секунды.
VD>Да не чаще он используется. И как ты правильно заметил от него никуда не деться. Да и уменьшить его уже не удастся без потери информации. А вот заменить try/finally using-ом можно легко. Причем это только увеличит объем информации (паттерн будет виден без мысленного распознования). Да и ошибиться будет куда сложнее.
не во всех случаях можно using приенять. сколько у тебя в проекте using и сколько namespace, посчитай если не лень? согласен с тем что ошибится сложнее с using, но это если редактировать код с помощью notepad, а там можно и закрывающюю скобку у namespace забыть. нормальный редактор тебе сразу покажет что ты забыл осводобить ресурс (ИДЕЯ знает типичные паттерны).
VD>Это частный случай. От использования и управления ресурсами все равно никуда не деться.
весь код и состоит из нескольких таких частных случаев. почти все они примерно в такие конструкции укладываются легко. в итоге получается намного более чистый код без пачки using или try/finally.
VD>Вообще-то мы говорим о языке. Ну, да если говорить о платформе, то лично мне в Яве не нравится в первую очередь не JVM, а именно язык. Нельзя сказать, что в нем мне не нравится только синтаксический оверхэд, но и он влияет на отношение. В купе с некоторым количеством неустраненных граблей и неудобным интеропом он действительно отталкивает от языка, и как следствие от платформы.
это субъективно. мне например в .НЕТ ненравятся namespaces, общепринятый стиль наименования (лень мне Shift все время жать) и мне кажется что делегаты совершенно не читаемы по сравнению с анонимными классами. кому-то наоборот эти вещи нравятся. но объективно на практике это ни на что не влияет. кстати, если вдруг будешь что-то на Жабе писать тебе с интеропом скорее всего не придется столкнутся ни разу. просто другой круг задач.
VD>Я бы вообще поставил вопрос по другому. Я вижу только два приемущества в Яве перед дотнетом. 1. Она перенесена на намного большее количество платформ. 2. Для нее есть больше фрэймворков и серверов в области разработки корпроративного ПО.
вот, это уже объективные факты. причем я бы добавил 3. бесплатна, думаю это скоро будет весьма актуально в свете борьбы с пиратстовом 4. огромный выбор различного готового софта на все случаи жизни и личто свой самый важный пунктик 5. совершенно другие задачи приходится решать Жаба программисту, как правило это сервер сайд с болшими нагрузками и распределенной средой, мне этот класс задач намного более интересен.
.НЕТ хорошо подходит для десктопных приложений под Винду. это его ниша и посягать на нее никто всерьез не пытается, хотя, OpenOffice вполне нормально работает и написан вообще на С++ в основном... еще я не понимаю почему таже ИДЕЯ (само существование которой ИМХО перевешивает все субъективные плюсы C#) написанная на Жабе небольшой питерской командой легко делает ВС над которым работает столько людей, причем на родном для МС поле — десктопные приложения.
VD>Тройку дней на что? Ты серьезно считашь, что написать плагин к ИДЕЕ полностью интегрирующий Syntactic Extender — это занятие на тройку дней? Ну, ты крут!
не полностью, конечно. думаю что за это время вполне можно взять ИДЕЙный плагин от какого-нибудь другого языка (GroovyJ например) и переделать его на поддержку большинства конструкций аналогичных C# — всяких там using и т.п.
кстати говоря, я бы был непротив отлаживать код полученный после применения Syntax Extender, по крайней мере можно breakpoint поставить на .close() а не не using.
Здравствуйте, WolfHound, Вы писали:
WH>Нормальные люди используют using и соеденения возвращаются в пул сразуже после того как с ним поработали. WH>Просто Влад говорит о том что если гдето какойто разбдолбай забудет это сделать то ГЦ за ним приберет.
а я говорю о том что ЖЦ НЕ приберет в разумные сроки. когда он будет вызван будет уже слишком поздно. соот-но финалайзер совершенно бесполезен в данном случае и вообще практически везде.
WH>Быть может в жабе сборка мусора и занимает секунду но в .НЕТ даже полная сборка происходит на порядки быстрее.
да ну? это для какого дерева объектов? если их, скажем, 15млн (типичный случай, кстати), то все равно соберет все за 10мс? кстати, а в .НЕТ вообще можно посмотреть статистику и графики в рантайме о работе ЖЦ?
WH>А для .НЕТ есть RFD
посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.
N>>кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе. WH>Гм... а зачем что-то еще вызывать?
ну, как сказать... вообще-то commit() надо вызывать. даже если произошли некоторые типы exceptions.
Здравствуйте, Sinclair, Вы писали:
S>Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.
Ладно, здесь я действительно мало чего знаю. Но вот какая штука — мне почему-то эти знания представляются неким ненужным мусором для моей работы — это то, что отнимает время, забиват голову и не дает ни малешего кайфа.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
> Вот зачем на каждый цвет создавать отдельный карандаш? Лично я не вижу в этом ни малейшей рациональности. >Троечники проектировали. Серые безнадежные троечники.
Ну все-таки смысл в этом был,
вся эта идея CreateObject\SelectObject\DeleteObject зародилась еще в
win 3.11 когда память была ценным ресурсом и процессоры были намнооого меделнее.
Я помню, читал книгу по программрованнию для win 3.11 (там еще OWL был , и раздел посвященный GDI
был пропитан трепетным отношениям к созданиям\удалением объектов..
Кроме того GDI решает дополнительно еще другие задачи — запись в метафайлы, печать и
работу терминал клиента.
Например когда мы рисуем линию , она не рисуется сразу, а запоминается информация, что мы таким то пером, нарисовали
линию там то. Есть даже функции которые управляют эти поведением — GdiSetBatchLimit и GdiFlush.
Другое дело что эти возможности нужны только в 10% случаев ...
А вот GDI+ точно троечники писали . Не понимаю почему 250 сглаженных линий толщиной 2px рисуются ~0.3 секунды.
AntiGrain делает это за 30 ms.
Здравствуйте, McSeem2, Вы писали:
MS>Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.
У Pen есть такая фигня как:
public void RotateTransform(float angle)
или более общий вариант:
System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)
Как раз для твоего случая сгиба рукава и полосочек
Здравствуйте, n0name2, Вы писали:
N> посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.
NHibernate — далеко не самый удобный ORM-Tool, и далеко не самый производительный. Остает от датасетов более чем в 2 раза, в то время как RFD не отстает или даже иногда обгоняет. При чем у RFD есть потенциал выжать еще примерно 30%, и я даже знаю где (предлагал как-то типизированные ридеры для исключения боксинга простых типов)
Далее. Из опыта собственной системы. На момент разработки ГОРАЗДО удобнее всякие ограничения/характеристики/маппинг полей описывать в виде аттрибутов прямо в коде. Почему — из-за частого рефакторинга. У нас по-любому аттрибуты остаются привязанными к конкретным полям и классам. А попробуй повторить тот же трюк с NHibernate с его внешним XML-описанием...
Однако, ближе к релизу гораздо удобней внутреннее описание перевести во внешнее, т.к. такой способ лучше сопровождаем.
vdimas wrote: > Далее. Из опыта собственной системы. На момент разработки ГОРАЗДО > удобнее всякие ограничения/характеристики/маппинг полей описывать в виде > аттрибутов прямо в коде.
Это уже можно делать в обычной Hibernate, в NHibernate тоже явно должно
быть.
> А попробуй повторить тот же трюк с NHibernate с его внешним XML-описанием...
Элементарно, Ватсон. IDEA поддерживает рефакторинг в XML-файлах.
ReShaper вроде бы тоже
Здравствуйте, McSeem2, Вы писали: MS>Ладно, здесь я действительно мало чего знаю. Но вот какая штука — мне почему-то эти знания представляются неким ненужным мусором для моей работы — это то, что отнимает время, забиват голову и не дает ни малешего кайфа.
Опять же, надо отличать "не хочу знать" от "непонятно". Пока что твои жалобы выглядят, мягко говоря, неубедительно. Что, программа на С++ волшебно нашла бы файл, не лежащий рядом с ее екзешником? Студия кладет результат в bin/debug уже как минимум четыре версии, так что вряд ли ты не знал, что исполняемый файл запустится не в фолдере проекта.
Или Image.FromFile() прямо так невозможно найти, с учетом интеллисенса и документации? В жизни не поверю, что в повседневном программировании ты не пользуешься F1.
И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>У Pen есть такая фигня как: V>public void RotateTransform(float angle)
V>или более общий вариант: V>System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)
V>Как раз для твоего случая сгиба рукава и полосочек
Толку от этого нет. Надо что-то типа:
Pen.RotateToTangentOfEachLineSegment() — без параметров!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, vdimas, Вы писали:
V>NHibernate — далеко не самый удобный ORM-Tool, и далеко не самый производительный. Остает от датасетов более чем в 2 раза, в то время как RFD не отстает или даже иногда обгоняет. При чем у RFD есть потенциал выжать еще примерно 30%, и я даже знаю где (предлагал как-то типизированные ридеры для исключения боксинга простых типов)
думаю, это особенности портирования NHibernate на .НЕТ или того что ты им неправильно пользуешься (настроек там много разных)... у RFD вообще нет и 10% тех возможностей которые есть в нормальном Жабном Hibernate.
V>Далее. Из опыта собственной системы. На момент разработки ГОРАЗДО удобнее всякие ограничения/характеристики/маппинг полей описывать в виде аттрибутов прямо в коде. Почему — из-за частого рефакторинга. У нас по-любому аттрибуты остаются привязанными к конкретным полям и классам. А попробуй повторить тот же трюк с NHibernate с его внешним XML-описанием... V>Однако, ближе к релизу гораздо удобней внутреннее описание перевести во внешнее, т.к. такой способ лучше сопровождаем.
Hibernate уже давно имеет и то и другое — на любой вкус. кстати в ИДЕЕ действительно очень мощный XML редактор.
Здравствуйте, Sinclair, Вы писали:
S>Опять же, надо отличать "не хочу знать" от "непонятно". Пока что твои жалобы выглядят, мягко говоря, неубедительно. Что, программа на С++ волшебно нашла бы файл, не лежащий рядом с ее екзешником? Студия кладет результат в bin/debug уже как минимум четыре версии, так что вряд ли ты не знал, что исполняемый файл запустится не в фолдере проекта.
Вообще-то, результаты кладутся в Debug или Relese с допотопных времен. И тем не менее, при запуске из IDE такущий каталог указывает на каталог проекта (они явно делают cd). Это было вполне логично. Зачем понадобилось менять — не понятно.
S>Или Image.FromFile() прямо так невозможно найти, с учетом интеллисенса и документации? В жизни не поверю, что в повседневном программировании ты не пользуешься F1.
Почти не пользуюсь. Если что-то надо, то Google, поскольку в MS Help'e фиг чего найдешь. Это же смешно — идем в MSDN, и не находим того, что надо (релевантность поика около нуля). Гугл как правило дает первую же ссылку куда надо.
Что же касается Image.FromFile() то сейчас опять посмотрел — нету. Причем Save — есть. Потом понял, что не так смотрел. Я-то по наивности думал как: Image img = new Image(); img.FromFile(. . .); А оказалось что метод статический! А у класса Bitmap — есть и Load и Save как члены класса. А у Image — "Load" называется "FromFile" и является статической функцией. Где логика? А еще ты что-то упоминал про засаду с блокировками файлов из за запоздалых вызовов Dispose.
S>И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
А вот получается так. Когда надо что-то сделать, берется самое очевидное, подходящее по смыслу название и оно не срабатывает! Кстати, в WinAPI — то же самое.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, n0name2, Вы писали:
N>а я говорю о том что ЖЦ НЕ приберет в разумные сроки. когда он будет вызван будет уже слишком поздно. соот-но финалайзер совершенно бесполезен в данном случае и вообще практически везде.
Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же остановят и произведут сборку нулевого поколения. До этого ни одна сволочь не сможет сделать не шагу в управляемом мире.
А псоле сборки у меня уже будет куча хэндлов. Ну, и не надо забывать то, что сказал Вольфхаунд. ЖЦ — это подстраховка. В грамотном коде 99% будет висеть на using-ах и ЖЦ вообще не потребуется задействовать.
Скорость же сборки мусора в нулевом поколении очень высокая (несколько микросекунд). Причем чем чаще вызваешь, тем бысрее работает. Одна проблема некоторые объкты могут нечаяно протолкнуться в вледующее поколение и прийдется делать более накладную сборку других поколений. Хотя первое поколение тоже довольно дешево.
N>да ну? это для какого дерева объектов? если их, скажем, 15млн (типичный случай, кстати), то все равно соберет все за 10мс? кстати, а в .НЕТ вообще можно посмотреть статистику и графики в рантайме о работе ЖЦ?
Нулевое поколение содержит только молодые объекты. К тому же его размер подстраивается под размер кэша, так что скорость его сборки — это даже не десятки милисекунд. Это микросекунды на современных компьютерах.
N> посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.
Это ты зря. Это разные подходы.
N>ну, как сказать... вообще-то commit() надо вызывать. даже если произошли некоторые типы exceptions.
Для забытых соеденений и соеденений при работе с которыми произошли исключения нужно не commit вызвать, а откат. Вот при возвращении в пул можно проверить состояние транзакции и откатить ее если она еще активна.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
S>>Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.
MS>Ладно, здесь я действительно мало чего знаю. Но вот какая штука — мне почему-то эти знания представляются неким ненужным мусором для моей работы — это то, что отнимает время, забиват голову и не дает ни малешего кайфа.
Э... Столько времени как в этом форуме у тебя ни один дотнет не отнимет. Так что это явно натянутый аргумент.
Что до трудности получения знаний, то надо признаться, что ты лихо портировал код с FW 2.0 на 1.1 и еще разобрался как картинку с диска загрузить. Думаю, что если бы ты имел бы подобные познания в ВыньАПИ как в дотнете, то вряд ли тебе удалось бы вот так вот в лоб подобный пример переписать. Так что в этом плане все ОК.
ЗЫ
Ты вот попробуй написать простенькую программку показывающую текущий режим сглаживания шрифтов в ХРюше и позволяющую его переключить. Я тут как-то вынужден был сделать это через ВыньАПИ. Вот это был секс! Вспомнил, шо называется, молодость.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же > остановят и произведут сборку нулевого поколения. До этого ни одна > сволочь не сможет сделать не шагу в управляемом мире.
Emphasis mine.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, vdimas, Вы писали:
V>>У Pen есть такая фигня как: V>>public void RotateTransform(float angle)
V>>или более общий вариант: V>>System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)
V>>Как раз для твоего случая сгиба рукава и полосочек
MS>Толку от этого нет. Надо что-то типа: MS>Pen.RotateToTangentOfEachLineSegment() — без параметров!
Берешь шаг в 1, согласно раpрешению устройства (т.е. 1 пиксел, например), и рисуешь каждый раз линию на эту длину.
MS>Почти не пользуюсь. Если что-то надо, то Google, поскольку в MS Help'e фиг чего найдешь. Это же смешно — идем в MSDN, и не находим того, что надо (релевантность поика около нуля).
Ну так никто и не говорил, что поисковый движок MSDN лучше, чем у Google. Зато по индексу они ищут намного быстрее. MS>Гугл как правило дает первую же ссылку куда надо. MS>Что же касается Image.FromFile() то сейчас опять посмотрел — нету. Причем Save — есть. Потом понял, что не так смотрел. Я-то по наивности думал как: Image img = new Image(); img.FromFile(. . .); А оказалось что метод статический!
Совершенно верно — не так смотрел. Надо было так:
— открываешь MSDN (у меня он вообще все время открыт)
— набираешь в индексе System.Drawing.Image
— переходишь в нижнем списке на System.Drawing.Image members
Все. Дальше пробегаешь глазами список мемберов и находишь FromFile. С пометкой S. MS> А у класса Bitmap — есть и Load и Save как члены класса. А у Image — "Load" называется "FromFile" и является статической функцией. Где логика? А еще ты что-то упоминал про засаду с блокировками файлов из за запоздалых вызовов Dispose.
S>>И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
MS>А вот получается так. Когда надо что-то сделать, берется самое очевидное, подходящее по смыслу название и оно не срабатывает! Кстати, в WinAPI — то же самое.
Гм. А что, где-то есть такие места, где все вообще очевидно?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
MS>А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же >> остановят и произведут сборку нулевого поколения. До этого ни одна >> сволочь не сможет сделать не шагу в управляемом мире. C>Emphasis mine.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
MS>>А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
AVK>Тима скорее всего имел ввиду Dispose.
Не, не. Диспоз бессмысленно. Тогда вообще зачем коворить ЖЦ о доп-памяти. Он имелл в виду финалйзер. Просто ТК у нас новичёк и не знает, что при плюсовиках лучше не говорить слово "деструктор" в отношении дотнета.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Denis_TST, Вы писали:
D_T>А вот GDI+ точно троечники писали . Не понимаю почему 250 сглаженных линий толщиной 2px рисуются ~0.3 секунды. D_T>AntiGrain делает это за 30 ms.
Думаю, они рассчитывали на то что эта операция будет осуществляться аппоратно. Ведь 30 мс — это тоже неприемлемо много.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Тима скорее всего имел ввиду Dispose.
VD>Не, не. Диспоз бессмысленно.
Как раз очень осмысленно. Если программист ручками позвал диспоз до сборки мусора и в нем дорогие ресурсы были освобождены, то провоцировать преждевременную сборку мусора уже не нужно.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
ANS>>Для этого нужно чтобы вызов вышел из неуправляемой среды и вернулся назад. Имхо, в виду претензии управляемой среды на самодостаточность, чаще всё заканчивается на первом шаге.
AVK>Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
Ага. Согласен. Это единственный случай, или есть еще примеры?
Впрочем система с материализацией стека работает. Значит проблема решаемая.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
ANS>Ага. Согласен. Это единственный случай, или есть еще примеры?
Есть еще — TCP-сервер например или ASP.NET приложение под IIS.
Здравствуйте, AndrewVK, Вы писали:
AVK>Как раз очень осмысленно. Если программист ручками позвал диспоз до сборки мусора и в нем дорогие ресурсы были освобождены, то провоцировать преждевременную сборку мусора уже не нужно.
"Если" тут не проходит. А то от первого забывчатого у тебя нулевое поколение будет собираться в цикле.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
) подход современных Java или WinForms.net:
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
