Есть ли проблемы с производительностью при определении свойства пользовательского типа в C #? - PullRequest
0 голосов
/ 30 мая 2011

Скажите, у меня есть четыре класса A, B, C и D.

D имеет свойство: Имя (строка)

C имеет свойство: D1 (тип D)

B имеет свойство: C1 (тип C)

A имеет свойство B1 (тип B)

С A1 в качестве экземпляра A я могу получить доступ: A1.B1.C1.D1.Name

Есть ли проблемы с производительностью?

Насколько далеко может проживать собственность, что не окажет существенного влияния на производительность?

Или есть ли предел этой иерархии?

Ответы [ 5 ]

4 голосов
/ 30 мая 2011

Нет проблем с производительностью, она может пойти так глубоко, как вы хотите (до определенного предела, если я правильно помню. Однако, если вы нажмете это, у вас будут другие, более острые проблемы).

Кроме того, хотя переход к графу объектов не очень дорогой, произвольный код в методах получения может быть.

1 голос
/ 30 мая 2011

С некоторым быстрым профилированием на моей машине ++ для тривиального свойства, которое имеет глубину одного уровня, запускается за 3 наносекунды, то же самое свойство, когда вложенные 10 глубоких прогонов за 6 наносекунд ... так что, если вы делаете это,пару миллионов раз в секунду это может быть что-то, на что можно смотреть, но в большинстве случаев оно будет незначительным.

1 голос
/ 30 мая 2011

Если все свойства в цепочке запечатаны (по умолчанию) и геттеры тривиальны, то JITter, вероятно, сможет встроить цепочку вызовов. Вы будете выполнять последовательность поиска по указателю, так что технически это будет не так быстро, как если бы А имел копию имени, но издержки вряд ли будут значительными.

Если какое-либо из свойств в цепочке является виртуальным, то я полагаю, что JITter не сможет встроить вызовы, и вы будете нести издержки на один или несколько вызовов функций (свойство получает). Это все еще очень мало (опять же, при условии, что геттеры тривиальны).

Как всегда, единственный способ убедиться - это измерить. И помните о том, что вы измеряете: если вложенная цепочка оказывается, скажем, на 50% медленнее, чем у А, имеющего собственную копию имени, это не означает, что это имеет большое значение, если ваша программа не тратит большое количество его время выполнения на том Имени получится - крайне маловероятно! Поэтому сначала сделайте правильное - сначала сделайте программу удобочитаемой и поддерживаемой - и если вы измеряете и обнаружите, что она является узким местом, то посмотрите на ее оптимизацию.

0 голосов
/ 30 мая 2011

Я давно не занимался .net, поэтому примите мой ответ с должными сомнениями. Я думаю, что компилятор должен оптимизировать геттер - если он не делает что-то очень сложное. Остается штраф, который вы платите за переход по другому адресу в памяти. Например, ваши объекты в памяти могут быть в любом порядке, например, так: D [другие данные] С В Таким образом, для каждого запроса вы запрашиваете адрес в памяти, который может вызвать небольшие замедления и очень вероятные сбои страниц (это также верно в других случаях). Однако это только для ответа на ваш вопрос. На практике вам вряд ли нужно это учитывать. Если вы не пишете какой-то внутренний цикл критичного ко времени и очень сложного алгоритма, разница во времени выполнения действительно близка к 0.

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

0 голосов
/ 30 мая 2011

Учитывая, что вы не переусердствуете, нет, это не проблема. В реальных сценариях объектно-ориентированное программирование требует такого типа свойств, например, person.personalDetails.address.city

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...