Какова стоимость выполнения сравнений строк для INotifyPropertyChanged?

Question

Мне было интересно, почему MS решила использовать строки в дизайне INotifyPropertyChanged?

Мое первоначальное беспокойство было связано с большими расходами на сопоставление строк при каждом уведомлении об изменениях, и мне было интересно, следует ли содержать мои имена свойств короткими, чтобы помочь с сравнениями.

Однако, учитывая, что строки являются неизменяемыми в .Net, я задавался вопросом, достаточно ли времени выполнения для повторного использования экземпляров строк через какую-либо хеш-таблицу, поэтому сравнения фактически являются сравнительным сравнением?

Кто-нибудь знает детали реализации, или если нет, то почему MS спроектировала его так, как они это сделали?

Answer 1

Если бы это было не string, что бы вы предложили? Это не может быть PropertyInfo, так как не все типы, которые поддерживают это, используют статическое типирование - например, DataTable предоставляет настраиваемую модель свойств для целей привязки, так как не многие другие типы (через любой из ICustomTypeDescriptor, TypeDescriptionProvider или ITypedList).

Даже если был в PropertyInfo, или даже если это был PropertyDescriptor, вы не могли бы сделать сравнение по этому вопросу: а: это заняло бы много работы, чтобы получить контрольный поиск, б: вы даже не гарантированы (например, для PropertyDescriptor), чтобы вернуть тот же объект каждый раз, когда вы смотрите.

Значит, вы, вероятно, в конечном итоге сравниваете имя (a string) в любом случае.

С помощью string, это дешево, чтобы поднять это событие, и довольно дешево сравнить - сравнение строк довольно быстро, учитывая, что большинство имен свойств довольно короткие, а почти все - менее 30 символов. Это будет очень быстро сравнивать, и это не узкое место. В большинстве случаев «что делать теперь, когда он изменился» займет лот больше времени, чем сравнение этой строки.

Я не имею осуществления передо мной, но я бы надежда, что проверка строки равенство в основном:

• же ссылка? возврат подлинный
• другой длина? return false
• сравнить char-by-char; вернуться ложным в первой разности
• возвращающие

поэтому он не должен даже быть проблемой, если все ваши имена свойств не являются: такой же длины, и б: очень значительная длина

В основном: не беспокойтесь об этом.

Answer 2

Всякий раз, когда вы создаете новую строку, она будет занимать свое собственное пространство в памяти, независимо от того, существует ли строка с тем же содержимым.

С другой стороны, когда вы явно назначаете строковую переменную другой, копируется только ссылка. Использование констант - еще один способ сохранить память.

Повторное использование экземпляров с помощью механизма, такого как хеш-таблица, потребует гораздо больших служебных и сравнительных механизмов, которые будут вызываться всякий раз, когда создается строка. Вероятно, в большинстве случаев это будет скорее проблемой производительности, чем просто сохранить еще пару байтов.

Answer 3

Если вы заинтересованы в деталях реализации, вы можете использовать JustDecompile от Telerik и посмотреть, как они это сделали. Насколько важны строки в INotifyPropertyChanged, ответ является отражением. Я сомневаюсь, что они содержат ссылку на получение производительности для практически тривиальной задачи. Какое количество уведомлений вы говорите? Обычное приложение WPF/SL не имеет проблем с производительностью из-за сравнения строк в INotifyPropertyChanged.

Answer 4

Почему MS спроектировала его так, как они сделали?

Потому что им нужен гибкий подход, и он достаточно быстр. Существует немало вещей, когда свойство меняется, поиск строки не будет узким местом.

Свойства зарегистрированы в некоторой базовой структуре, поиск будет похож на словарь, означающий, что HashCode обеспечит эффективный доступ. Строки все будут интернированы, но это недостаточно надежное, чтобы определить равенство из ссылок.

Сохранение наименований собственности короткими не принесет никаких измеримых улучшений, лучше использовать значащие имена.

Answer 5

Я бы подумал о потребителях - если вы являетесь сеткой привязки данных, у вас уже есть имя свойства как строка для интересующих вас столбцов. Также рассмотрите вопрос о создании события - для получения PropertyInfo не дешево, а hardcoding - строка.

Answer 6

Я думаю, что сравнение строк вообще не дорого, по сравнению с другими механизмами (например, привязками), поэтому строки определенно не являются узким местом.

Это говорит о том, что использование константных строк в вашем коде (я имею в виду PropertyChanged(this, new PropertyChangedEventArgs("MyProperty"))) быстро, но я лично предпочитаю использовать отражение для динамического получения имени свойства: оно требует больше работы, но оно значительно улучшает ремонтопригодность и уменьшает количество ошибок (наиболее распространенным является «Я переименовал свою собственность, но я забыл изменить параметр события PropertyChanged»).