Здравствуйте, criosray, Вы писали:
C>Раз: Improving Microsoft .NET Compact Framework-based Application Form Load Performance C>Два: March 2002 C>Три: Microsoft® .NET Compact Framework 1.0
C>Акелла промахнулся. :down:
Ну да, а что, что-то принципиально поменялось? Я именно тогда эту статью и читал. Более того, и сейчас используется огромное количество устройств с .NET Compact Framework 1.0.
Здравствуйте, COFF, Вы писали:
COF>Пожалуйста, не поленился и специально нашел такой пример COF>http://www.cnblogs.com/jerryzhao/archive/2007/08/29/873986.html COF>One of the ways in which you can improve the performance of loading a form is by reducing the number of method calls made during form initialization.
Не, ты правда относишь эти рекомендации в разряд общих, относящихся ко всему Фреймворку в его текущей реализации, ммм?
Здравствуйте, criosray, Вы писали:
C>Быстрый код получается не тогда, когда Вы тратите 90% времени на техническую оптимизацию кода и 10% на алгоритмизацию, а 90% на алгоритмизацию, 10% на техническую оптимизацию.
Конечно я в курсе, что любую программу можно ускорить если заменить сортировку пузырьком на что-то более продвинутое :)
Здравствуйте, COFF, Вы писали:
C>>Раз: Improving Microsoft .NET Compact Framework-based Application Form Load Performance C>>Два: March 2002 C>>Три: Microsoft® .NET Compact Framework 1.0
C>>Акелла промахнулся.
COF>Ну да, а что, что-то принципиально поменялось? Я именно тогда эту статью и читал. Более того, и сейчас используется огромное количество устройств с .NET Compact Framework 1.0.
Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5
Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?
C>>Быстрый код получается не тогда, когда Вы тратите 90% времени на техническую оптимизацию кода и 10% на алгоритмизацию, а 90% на алгоритмизацию, 10% на техническую оптимизацию.
COF>Конечно я в курсе, что любую программу можно ускорить если заменить сортировку пузырьком на что-то более продвинутое
Очень рад, что Вы знаете сортировку пузырьком. Надеюсь, Вы так же знаете, что это самое ускорение от замены сортировки пузырьком на "что-то более продвинутое" далеко не всегда рационально?
Здравствуйте, criosray, Вы писали:
C>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5 C>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?
Здравствуйте, criosray, Вы писали:
C>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5 C>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?
Да дело даже не в этом. COFF приводит пример частной задачи, которая к самому .Net мало имеет отношения.
Так что написано:
For example, the code generated by the Forms Designer for setting the location and size of a control uses two method calls for setting these properties, like this
Т.е. это проблема Forms Designer, а никак не .Net.
И если бы дизайнер генерил не очень удачный C++ код, к нему можно было бы предъявить точно такие же претензии.
Здравствуйте, COFF, Вы писали:
C>>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5 C>>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?
COF>Нет, не вижу разницы. Серьезно
Зачем же так откровенно выставлять на показ свое невежество?..
Здравствуйте, MxKazan, Вы писали:
MK>Т.е. это проблема Forms Designer, а никак не .Net. MK>И если бы дизайнер генерил не очень удачный C++ код, к нему можно было бы предъявить точно такие же претензии.
Хорошо, вот более релевантная ссылка — просто не имею привычки (к сожалению) локально сохранять все статьи, которые я прочитал, чтобы при случае была возможность блеснуть на rsdn :) Поэтому пришлось погуглить немного
Здравствуйте, COFF, Вы писали:
C>>Зачем же так откровенно выставлять на показ свое невежество?..
COF>То есть таки под мобильные устройства надо писать на C++, не используя CF, я так понимаю этот вот пассаж про невежество?
Здравствуйте, MxKazan, Вы писали:
COF>>Пожалуйста, не поленился и специально нашел такой пример COF>>http://www.cnblogs.com/jerryzhao/archive/2007/08/29/873986.html COF>>One of the ways in which you can improve the performance of loading a form is by reducing the number of method calls made during form initialization. MK>Не, ты правда относишь эти рекомендации в разряд общих, относящихся ко всему Фреймворку в его текущей реализации, ммм?
Справедливости ради, часть этих рекомендаций действительно общего характера. К примеру, про avoid boxing/unboxing совершенно верно написано (впрочем, заметное падение производительности будет лишь на многократно повторяющихся операциях в короткий промежуток времени...).
Но вот про "избегайте использовать много мелких объектов и мелких методов" — полный бред.
Здравствуйте, COFF, Вы писали:
COF>Хорошо, вот более релевантная ссылка — просто не имею привычки (к сожалению) локально сохранять все статьи, которые я прочитал, чтобы при случае была возможность блеснуть на rsdn Поэтому пришлось погуглить немного COF>http://xman892.blogspot.com/2005/11/compact-framework-performance-hints.html
И где там про то, что всё нужно пихать в один большой метод? Наоборот вот на инлайнинг указывают...
Я так и не понял, причем здесь рекомендации по Компакт FW и обычный PC'шный FW?
А так списочек вполне стандартный, но он лишь указывает на возможные узкие места.
Кстати, в С++ нет виртуальных методов? А, просматривая, например, исходники Гугл Хрома, не смущает что и там есть всякие set/get а-ля свойства?
ГВ>>>- bind — это уже не низкий уровень; G>>Очень низкий. Связыванием должен заниматься компилятор, а не программист. Для простых типов и арифметических операция в C++ этого удалось добиться, а для всех остальных — нет. ГВ>Ну вот уже ты, по-моему, путаешься. Описанием связывания в любом случае занимается программист.
Да ну. Вот я пишу лямбду на C#: x => x.SomeMethod() == someValue, при этом someValue создает полноценное лексическое замыкание, которое в С++ невозможно вообще. Где здесь связывание?
ГВ>И потом, bind — это, в общем-то, не полноценные лямбды, как ни крути. Показательно то, что на C++ их можно реализовать. Показательно то что их нет в современном языке.
? G>>Хочу. Код также свидетельствует о черезмерной низкоуровневости С++. Метаинформацией о типах дожен заниматься рантайм, а не программист. ГВ>А где ты там метаинформацию нашёл?
TypeName, TrivialClassTraitDep1, TrivialClassTraitDep2, методы контейнера RegisterDep1, RegisterDep2, RegisterDep. В той или иной мере реализуют метаинформацию.
Здравствуйте, gandjustas, Вы писали:
ГВ>>>>- bind — это уже не низкий уровень; G>>>Очень низкий. Связыванием должен заниматься компилятор, а не программист. Для простых типов и арифметических операция в C++ этого удалось добиться, а для всех остальных — нет. ГВ>>Ну вот уже ты, по-моему, путаешься. Описанием связывания в любом случае занимается программист. G>Да ну. Вот я пишу лямбду на C#: x => x.SomeMethod() == someValue, при этом someValue создает полноценное лексическое замыкание, которое в С++ невозможно вообще. Где здесь связывание?
А упоминание someValue вот здесь: x => x.SomeMethod() == someValue — это что, как не описание того, что нужно связать, сиречь, описание связывания?
Ровно то же самое делается на C++: bind(&X::SomeMethod, _1) == someValue. И тоже, знаешь ли, полноценное лексическое замыкание. В конце концов, главное при создании замыкания что? ИМХО — связать переменные локального контекста с параметрами (или переменными) некоторой функции. Совершенно не важно, используем мы ссылки или значения. По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
Но и в том, и в другом случае программист описывает, что именно связыватся.
ГВ>>И потом, bind — это, в общем-то, не полноценные лямбды, как ни крути. Показательно то, что на C++ их можно реализовать. G> Показательно то что их нет в современном языке.
Как это — нет? А новый стандарт? А новый компилятор от MS (который, правда, я ещё не щупал)? Всё есть, вроде. И опять таки, bind — пусть и не полноценная замена, но по крайней мере, для "маленьких функций" — вполне подходящее решение. Примечательно же оно тем, что получено средствами самого C++.
ГВ>>>>P.S.: Не хочешь высказаться по IoC
? G>>>Хочу. Код также свидетельствует о черезмерной низкоуровневости С++. Метаинформацией о типах дожен заниматься рантайм, а не программист. ГВ>>А где ты там метаинформацию нашёл? G>TypeName, TrivialClassTraitDep1, TrivialClassTraitDep2, методы контейнера RegisterDep1, RegisterDep2, RegisterDep. В той или иной мере реализуют метаинформацию.
Хм. Я бы так не сказал, поскольку Traits используются для конструирования типа (для инстанцирования RegisterDep). Ну а сами RegisterDep просто зависят от типа используемого конструктора (учтём, что сигнатура = тип функции), точно так же, как и любая функция требует параметров вполне определённых типов. Но мы же не называем требование соблюдать типы параметров функции использованием метаданных. А не то, знаешь, можно любое наследование метаданными назвать.
Программист в данном случае должен только выбрать, как именно регистрировать в контейнере тот или иной тип. Но это всегда обязанность программиста, выбор нужного конструктора полностью на компилятор не переложишь.
Исключение, пожалуй, TypeName — эта структура, действительно, похожа на метаданные — то есть такие данные, которые сопоставляются типу, но прямо в него не включены. Но от TypeName можно избавиться посредством type_info — тогда метаданными будет заниматься только рантайм. Мне просто хотелось оставить возможность назначать объектам идентификаторы разных типов: GUID, int, const wchar_t * и так далее.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>>>- bind — это уже не низкий уровень; G>>>>Очень низкий. Связыванием должен заниматься компилятор, а не программист. Для простых типов и арифметических операция в C++ этого удалось добиться, а для всех остальных — нет. ГВ>>>Ну вот уже ты, по-моему, путаешься. Описанием связывания в любом случае занимается программист. G>>Да ну. Вот я пишу лямбду на C#: x => x.SomeMethod() == someValue, при этом someValue создает полноценное лексическое замыкание, которое в С++ невозможно вообще. Где здесь связывание?
ГВ>А упоминание someValue вот здесь: x => x.SomeMethod() == someValue — это что, как не описание того, что нужно связать, сиречь, описание связывания?
Только описание неявное, программисту не надо об этом заботиться, оно все само работает. Вариантов ошибиться нету.
ГВ>Ровно то же самое делается на C++: bind(&X::SomeMethod, _1) == someValue. И тоже, знаешь ли, полноценное лексическое замыкание. В конце концов, главное при создании замыкания что? ИМХО — связать переменные локального контекста с параметрами (или переменными) некоторой функции. Совершенно не важно, используем мы ссылки или значения.
Важно. Если связать что-нить с объектом в хипе, выделенном в текущем скоупе, и время жизни лямбды больше, чем текущий скоуп, то получится утечка.
ГВ>По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
Не надо торговаться. лямбды и замыкания в С++ ущербны.
ГВ>Но и в том, и в другом случае программист описывает, что именно связыватся.
Нет, в случае C# программист пишет функцию. Ему не надо вникать что там внутри компилятора происходит. В случае C++ он должен заниматься сввязыванием.
ГВ>>>И потом, bind — это, в общем-то, не полноценные лямбды, как ни крути. Показательно то, что на C++ их можно реализовать. G>> Показательно то что их нет в современном языке.
ГВ>Как это — нет? А новый стандарт? А новый компилятор от MS (который, правда, я ещё не щупал)? Всё есть, вроде. И опять таки, bind — пусть и не полноценная замена, но по крайней мере, для "маленьких функций" — вполне подходящее решение. Примечательно же оно тем, что получено средствами самого C++.
Ну и где этот стандарт?
ГВ>>>>>P.S.: Не хочешь высказаться по IoC
? G>>>>Хочу. Код также свидетельствует о черезмерной низкоуровневости С++. Метаинформацией о типах дожен заниматься рантайм, а не программист. ГВ>>>А где ты там метаинформацию нашёл? G>>TypeName, TrivialClassTraitDep1, TrivialClassTraitDep2, методы контейнера RegisterDep1, RegisterDep2, RegisterDep. В той или иной мере реализуют метаинформацию.
ГВ>Хм. Я бы так не сказал, поскольку Traits используются для конструирования типа (для инстанцирования RegisterDep). Ну а сами RegisterDep просто зависят от типа используемого конструктора (учтём, что сигнатура = тип функции), точно так же, как и любая функция требует параметров вполне определённых типов.
Это и есть метаданные типов.
ГВ>Программист в данном случае должен только выбрать, как именно регистрировать в контейнере тот или иной тип. Но это всегда обязанность программиста, выбор нужного конструктора полностью на компилятор не переложишь.
На компилятор — нет, а на контейнер — можно.
ГВ>Исключение, пожалуй, TypeName — эта структура, действительно, похожа на метаданные — то есть такие данные, которые сопоставляются типу, но прямо в него не включены. Но от TypeName можно избавиться посредством type_info — тогда метаданными будет заниматься только рантайм. Мне просто хотелось оставить возможность назначать объектам идентификаторы разных типов: GUID, int, const wchar_t * и так далее.
Ты считаешь что описание количества и типов параметров конструктора, совмещенное с методами создания объекта, не является метаданными?
Не стоит себя обманывать.
На type_info все не заменишь, типизированность пропадет, генериков в рантайме у С++ нету.
Здравствуйте, criosray, Вы писали:
C>Быстрый код получается не тогда, когда Вы тратите 90% времени на техническую оптимизацию кода и 10% на алгоритмизацию, а 90% на алгоритмизацию, 10% на техническую оптимизацию.
Назвать тот бред, что ты перечислил оптимизациями вообще язык не поворачивается. Ту чушь оптимизируют компиляторы (JIT или обычные). Ручное вмешательство там на сегодня только вредит, так как нарушает те самые партерный что оптимизируются компиляторами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, COFF, Вы писали:
COF>http://www.cnblogs.com/jerryzhao/archive/2007/08/29/873986.html
COF>One of the ways in which you can improve the performance of loading a form is by reducing the number of method calls made during form initialization.
Уважаемый! Прежде чем давать ссылки на что-то, не плохо было бы прочесть то на что даешь ссылку.
В этой ссылке написано, что если в API есть метод позволяющий задать значение за один раз, то нужно использовать его, а не несколько отдельных вызовов. Вот пример оттуда:
this.textBox1.Location = new Point(10,20);
this.textBox1.Size = new Size(72,23);
This can be consolidated into a single method call by using the Bounds property:
this.textBox1.Bounds = new Rectangle(10,20,72,23);
Самое смешно, что увеличение производительности тут достигается не за счет уменьшения времени затрачиваемого на лишний вызов, а за счет того, что оконной системе приходится меньше перерисовывать свое изображение и пересчитывать свои размеры.
Правило универсальное. Применимо и для любой программы написанной на С++. Так что мотай на ус.
ЗЫ
Не выставляй себя полным ламером. Молчи по тем темам в которых не шаришь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, criosray, Вы писали:
C>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5 C>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?
Этот пример справедлив и для настольного фрэймворка последней версии. Ты вчитайся в код. Там не о экономии на вызове метода речь идет. Там речь о том, что не надо устанавливать размеры окна в два приема, если тоже самое можно сделать за один прием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
