Как повлиять на другие элементы при наведении div

Во-первых, единственный способ ответить на вопросы о производительности - это попробовать в обоих направлениях и проверить результаты в реальных условиях.

Тем не менее, другие ответы, которые говорят, что «компилятор» не делает эту оптимизацию, потому что свойство может иметь побочные эффекты как правильные, так и неправильные. Проблема с вопросом (помимо фундаментальной проблемы, на которую просто невозможно ответить без фактической попытки и измерения результата) заключается в том, что «компилятор» на самом деле является двумя компиляторами: компилятор C #, который компилируется в MSIL и JIT-компилятор , который компилирует IL для машинного кода.

Компилятор C # никогда не делает такого рода оптимизацию; как отмечалось, для этого потребуется, чтобы компилятор подключался к вызываемому коду и проверял, что результат, который он вычисляет, не изменяется в течение всего срока действия кода вызываемого абонента. Компилятор C # этого не делает.

Компилятор JIT может. Нет причин, почему это не могло. Здесь есть весь код. Вполне возможно встроить свойство getter, и если джиттер определяет, что встроенное свойство getter возвращает значение, которое может быть кэшировано в регистре и повторно использовано, тогда оно имеет на это право. (Если вы этого не хотите, потому что значение может быть изменено в другом потоке, тогда у вас уже есть ошибка состояния гонки, исправьте ошибку, прежде чем беспокоиться о производительности.)

Действительно ли джиттер делает встроенную функцию fetch и затем регистрирует значение, я понятия не имею. Я почти ничего не знаю о дрожании. Но это разрешено делать, если сочтет нужным. Если вам интересно, делает оно это или нет, вы можете (1) спросить кого-то, кто находится в команде, которая написала джиттер, или (2) проверить jitted-код в отладчике.

И наконец, позвольте мне воспользоваться этой возможностью, чтобы отметить, что вычисления результатов один раз, сохранение результата и повторное использование его - это не всегда оптимизация . Это удивительно сложный вопрос. Оптимизировать все для оптимизации:

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

Короче говоря, вы не можете знать, записывать ли код для кэширования результата, а не пересчитывать его на самом деле (1) быстрее или (2) лучше выполнять , Лучшая производительность не всегда означает ускорение выполнения конкретной процедуры. Лучшая производительность - это выяснить, какие ресурсы важны для пользователя: время выполнения, память, рабочий набор, время запуска и т. д. - и оптимизация для этих вещей. Вы не можете этого сделать без (1) беседы с вашими клиентами, чтобы узнать, что им небезразлично, и (2) фактически измерить, чтобы увидеть, имеют ли ваши изменения измеримый эффект в нужном направлении.