Здравствуйте, aloch, Вы писали:
A>Ядро само по себе никому не нужно, если оно не будет окошки рисовать, файлы открывать и еще что-нибудь такое делать, ради чего вообще программы пишутся. И вот когда я рисую окошко "через ядро .Net" (а не напрямую, через WinAPI), я получаю внушительный расход памяти. Я, в принципе, не против и даже понимаю куда и зачем она использовалась.
Вот как раз окошки и файлы суть разные вещи. Файлы давай читать на .Net — память изличшне расходоваться не будет. А вот для окошек будет. И я как раз очень хорошо понимаю почему.
A>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".
Здрасьте А маршалинг? А апартменты? А IDispatch/TLB?
Здравствуйте, adontz, Вы писали:
A>Вот как раз окошки и файлы суть разные вещи. Файлы давай читать на .Net — память изличшне расходоваться не будет.
Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?
Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.
A>>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро".
A>Здрасьте А маршалинг? А апартменты? А IDispatch/TLB?
Для Windows 3.1 маршалиг как таковой был не нужен (там не было защиты памяти, все жили в одной "куче") — хотя в OLE 2 он был "по честному", очевидно для NT 3.1 (и для тормозов . Апартментов там тоже не было (т.к. не было threads). IDispath/TLB — по слухам — полностью разрабатывались командой Visual Basic (они делали OLE Automation) — какое же это ядро? Ядро COM — IUnknown + куча функций Co.... + реестр (для COM в Windows 3.1 был маленький реестрик — только HKCR)
Здравствуйте, aloch, Вы писали:
A>Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?
А кто сказал что эффективный строкой IO делается на основе класса System.String?! Вот в Си++ (который совсем unmanaged) есть scanf и std::cin. Предлагаю на досуге убедиться что скорость работы различается на порядки.
A>Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.
Можно указывать byte[], ничего зазорного тут нет. Лично я, когда нужна была эффективная работа, так и делал.
A>>>А вот для COM приктически ничего не нужно — IUnknown, вот и все его "ядро". A>>Здрасьте А маршалинг? А апартменты? А IDispatch/TLB?
A>Для Windows 3.1 маршалиг как таковой был не нужен (там не было защиты памяти, все жили в одной "куче") — хотя в OLE 2 он был "по честному", очевидно для NT 3.1 (и для тормозов . Апартментов там тоже не было (т.к. не было threads). IDispath/TLB — по слухам — полностью разрабатывались командой Visual Basic (они делали OLE Automation) — какое же это ядро? Ядро COM — IUnknown + куча функций Co.... + реестр (для COM в Windows 3.1 был маленький реестрик — только HKCR)
Маршалинг может быть не только в пределах одной машины. IDispatch и TLB неотемлемая часть СОМ, так как default marshaling делается именно на основе TLB. Короче в вопросе ты не разбираешься, как я погляжу.
Здравствуйте, adontz, Вы писали:
A>Можно указывать byte[], ничего зазорного тут нет. Лично я, когда нужна была эффективная работа, так и делал.
Да нет, конечно ничего зазорного в этом нет. Но смысл в том, что ты не сможешь в очень большом круге задачь ограничится этим byte[] — тебе будет нужна строка (ведь говорим об строковом вводе/выводке, а в .Net это System.String) (например, мы читаем xml-файл). Как только ты получшь из byte[] эту строку, ты "повесишь" ее в памяти до сборки мусора.
A>Маршалинг может быть не только в пределах одной машины.
В начале (в OLE 2.0 в Windows 3.1) ни о каком DCOM речи вообще не шло. Причем, обрати внимание, я не говорил о том, что в OLE 2 не было маршалинга. Но только для Windows 3.1 его можно было и не создавать.
Здравствуйте, aloch, Вы писали:
A>Да нет, конечно ничего зазорного в этом нет. Но смысл в том, что ты не сможешь в очень большом круге задачь ограничится этим byte[] — тебе будет нужна строка (ведь говорим об строковом вводе/выводке, а в .Net это System.String) (например, мы читаем xml-файл). Как только ты получшь из byte[] эту строку, ты "повесишь" ее в памяти до сборки мусора.
Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости.
Здравствуйте, adontz, Вы писали:
A>Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости.
Это конечно так, но .Net — это не C/C++. Много ты знаешь стандартных классов, которым можно вместо строки передавать byte[] или char[] вмето System.String?
Здравствуйте, aloch, Вы писали:
A>>Ещё раз, чтобы обработать byte[] как строку, например найти подпоследовательность символов, переводить byte[] в System.String нет необходимости. A>Это конечно так, но .Net — это не C/C++. Много ты знаешь стандартных классов, которым можно вместо строки передавать byte[] или char[] вмето System.String?
Ну вот char[] то как раз много куда можно передать. А соответствие byte[] <-> char[] вообще говоря неоднозначное.
Здравствуйте, aloch, Вы писали: A>Ну да — я из потока читаю, например, строки. Прочитал, посмотрел на строчку, прочитал следующую, когда я читаю следующую строку, то старая останется висеть в памяти (я не могу в string прочитать новое значение) — чем больше строк прочитаю, тем больше памяти отестся. Разве не так?
Старая строка будет собрана GC и очень быстро. Сборка нулевого поколения почти ничего не стоит. По расходу памяти это будет значительно лучше, чем выделять строчки в классическом хипе. A>Ну а если говорть так — я при помощи interop обращаюсь к API-функии ReadFile и в один и тот же буфер (byte[]) читаю данные, тогда да, тогда память не расходуется. Но многие ли так делают. Тогда и CreateWindow особого расхода памяти не потребует.
Никакого Interop не надо. Ты можешь точно так же читать в char[], но это вряд ли даст тебе значительный выигрыш по памяти.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Да я все это знаю — я сам сейчас программирую на С#, и возвразаться к старым способам особено не тянт (хотя и приходится).
Разговор шел о другом — о том, что технологии типа .Net (или Java) было практически не возможно реализовать на том "железе", на котором изначально реализовывался COM (да и сам Windows). Когда "железо" "подросло", то открылись совершенно новые возможности, которые привели к созданию новых технологий программирования, при этом старые технологии (COM) в утиль никто не отправляет.
А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.
Здравствуйте, aloch, Вы писали:
A>А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.
Прочины простые — надо было подождать, пока поменяется мышление программистов. До сих пор многие сидят на VC6 и пишут мелкие вещи на WinAPI потому что "быстрее работает". Было время когда классы, виртуальные функции считали плохой идеей.
Здравствуйте, aloch, Вы писали:
A>А то есть такая легенда (в основном она популярна среди линуксойдов) о том, что "Ни одна девелопмент технология Мелкомягких не живет дольше 5-10 лет, все уходит потом в треш и начинаются очередные маркетинговые крики — "наш аппроуч А был фиговым, в мусор его. Вот сейчас мы придумали аппроуч B! Который наконец таки решит ваши проблемы!"", при этом люди это говорящие совсем не понимают причин, по которым сначало создавалас A, а теперь можно использовать B.
Я себя к линуксоидам не отношу, но вот два раза наблюдал Дона Бокса на конференциях Микрософт.
Вот что из этого вышло: http://www.rsdn.ru/Forum/?mid=1482487
Здравствуйте, adontz, Вы писали:
A>рочины простые — надо было подождать, пока поменяется мышление программистов.
И типа оно сейчас само-собой поменялось? И, например, если бы не эта костность мышления, нам MS забабахала бы на 1 мегабайте памяти сборку мусора?
Или COM и OLE2 не меняли мышление "так сильно"?
И вообще, если задаваться целью сделать html layout (эдакий рисующий layout manager в терминах AWT) то я считаю подход который я использовал в Harmonia он наиболее
подходящий что-ли для такого рода use cases. В harmonia html используется именно как layout manager. DOM как таковой там не нужен. Сугубо parse/measure/draw методы + callback replace_widget(child_widget). Доводить конструкции типа tkhtml.tcl.tk до уровня полного html/css2.1 движка и ACID тестов я считаю пустой тратой времени. И все равно css2.1 всего спектра задач UI не решает. Например те же flex units в htmlayout (или flex аттрибут в XUL).
Т.е. нужно четко ставить задачу для чего и как оно.
Полный html/css rendering это достаточно нетривиальная штука. Там много деталей которые не должны торчать наружу.
Т.е. периметр движка должен быть компактным насколько это возможно.
Концептуально говоря... Не вчера родилась идея по разделению tiers.
Я считаю что html + css + behaviors как UI tier естественным образом замыкающий логику и представление UI это good thing (tm).
Такой подход позволяет опять же естественным образом отделить слой который отвечает за логику обработки и представления данных.
Эти два слоя должны обмениваться сугубо абстрактными данными в стиле CGI/form submit — json-messaging?. Такой подход позволяет как развязать данные
так и изолировать сущности/namespaces. Например обработку данных удобно делать в managed средах типа .NET и Java.
Собственно не зря .NET и Java так популярны на server side. И GC там в принципе работает (или может работать) детерменировано и эффективно — исполнил запрос — почистил память.
Т.е. по большому счету связка browser/server как модель взаимодейтвия UI/логика представляется достаточно устойчивой.
И в рамках desktop приложения такая модель "играет" хорошо. Даже более чем хорошо.
В качестве примера вот BugTracking system типа: http://www.seapine.com/ttpro.html
Я уверен что в случае htmlayout её можно сделать значительно интереснее и эффективнее.
А вот WPF почему-то представляется неподходящей технологией для такого рода приложений.
Скорее всего WPF и htmlayout имеют несколько разные среды обитания что-ли...
).jpg)
