1000 моделей нужно заполнить данными до того, как хоть одна из них будут отображаться. Фактор 13 это много.
Это вместо 400ms получаем 5 секунд. 5 секунд 100% нагрузки на ядро.
Неудивительно, что потом люди начинают жаловаться, что Silverlight тормозит (или садит батарейки в моем планшете) :)
Давайте просто не будем писать тормозной код. Преждевременная оптимизация — это грех, согласен. Но выбор изначально тормозной технологии — 100% гарантия тормозов в будущем и существенные издержки на их устранение.
Binding произносится как байндинг согласно всем моим англоязычным коллегам. Но может они ошибаются, плохо знают родной английский.
В итоге вы не сравнили ничего, точнее сравнили, но впустую. DependencyObject нужно использовать только в контексте с байдингом
Я сравнивал запись в свойство, а также возможность реагировать на изменение этого свойства изнутри класса. Понятное дело, что реагировать на изменение свойства хотелось бы в его родном виде, поэтому везде стоит typecast. Это мой обычный сценарий. Никаких натяжек.
Выигрывая в транспортировке значения как object в случае композитных data-binding, мы проигрываем в использовании этого свойства в коде, т.к. typecast и извлечение значение из Dictionary по ключу инстанса DependencyProperty — это все-таки накладные расходы.
Еще интересно покопаться в классах CLRPropertyListener и DependencyPropertyListener, станет ясно, что логика везде одинаковая…
Сколько значений в одно время может иметь Dependency Property?
Я не умоляю достоинств DependencyProperties, просто их место в контролах, которые уже написаны за нас. В статье же речь идет об удобном варианте создания ViewModel-ей. И как мне показалось, использовать DependencyObject в этом контексте не совсем разумно. Ну если только вам необходима анимация свойств у ваших ViewModel-ей :)
А насчет анимации — соглашусь, не подумал. Хотя уверен, что простые свойства тоже поддаются анимации. Другое дело, что это будет уже Frame-based, а не Time-based анимация, которой MS так гордится.
Да, в тест-проекте тестируется только запись свойства и перезапись с другим значением. Это нужно для того, чтобы выпятить на поверхность тот функционал, производительность которого я и хочу сравнивать.
Мой комментарий по поводу производительности дата-байндинга относился именно к впечатлению вцелом.
Давайте не будем забывать, что dependency properties это костыль, придуманный MS исключительно ради Attached properties, типо Grid.Column.
Остальное их испотзование притянуто за уши, т.к. Xaml замечательно работает и с простыми свойствами.
Они или какой-то другой facebook разрабатывают или на асме всё пишут?
пересадка поджелудочной — это вам не апендицит вырезать…
это очень серьезно
С другой стороны — остутствие конкуренции — это всегда плохо
А новые никто на Дельфях уже писать не будет — ибо это не программы, а хроники пикирующего бомбардировщика… ;)
Люди на C++ писали годами то, что на Delphi делалось за месяц.
Перекупить Хайльстберга — это зло, а Аршавина — обычное дело :)
Мыша такая плоская, что сумка не оттопыривается
Это вместо 400ms получаем 5 секунд. 5 секунд 100% нагрузки на ядро.
Неудивительно, что потом люди начинают жаловаться, что Silverlight тормозит (или садит батарейки в моем планшете) :)
Давайте просто не будем писать тормозной код. Преждевременная оптимизация — это грех, согласен. Но выбор изначально тормозной технологии — 100% гарантия тормозов в будущем и существенные издержки на их устранение.
Врага нужно знать в лицо :)
Баг пофикшен, теперь все как обычно :)
Во-первых, он не совсем обязательно должен быть protected.
Во-вторых, если параметром будет PropertyChangedEventArgs — это просто праздник какой-то в каждом сеттере его создавать :)
Я сравнивал запись в свойство, а также возможность реагировать на изменение этого свойства изнутри класса. Понятное дело, что реагировать на изменение свойства хотелось бы в его родном виде, поэтому везде стоит typecast. Это мой обычный сценарий. Никаких натяжек.
Выигрывая в транспортировке значения как object в случае композитных data-binding, мы проигрываем в использовании этого свойства в коде, т.к. typecast и извлечение значение из Dictionary по ключу инстанса DependencyProperty — это все-таки накладные расходы.
Еще интересно покопаться в классах CLRPropertyListener и DependencyPropertyListener, станет ясно, что логика везде одинаковая…
Я не умоляю достоинств DependencyProperties, просто их место в контролах, которые уже написаны за нас. В статье же речь идет об удобном варианте создания ViewModel-ей. И как мне показалось, использовать DependencyObject в этом контексте не совсем разумно. Ну если только вам необходима анимация свойств у ваших ViewModel-ей :)
А насчет анимации — соглашусь, не подумал. Хотя уверен, что простые свойства тоже поддаются анимации. Другое дело, что это будет уже Frame-based, а не Time-based анимация, которой MS так гордится.
Да, в тест-проекте тестируется только запись свойства и перезапись с другим значением. Это нужно для того, чтобы выпятить на поверхность тот функционал, производительность которого я и хочу сравнивать.
Мой комментарий по поводу производительности дата-байндинга относился именно к впечатлению вцелом.
Давайте не будем забывать, что dependency properties это костыль, придуманный MS исключительно ради Attached properties, типо Grid.Column.
Остальное их испотзование притянуто за уши, т.к. Xaml замечательно работает и с простыми свойствами.