На каком уровне компилятор C # или JIT оптимизируют код приложения?

Question

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

например:

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

Я хочу порекомендовать хороший справочник, который описывает, что происходит?

Answer 1

Возможно, вы захотите взглянуть на эти статьи:

JIT-оптимизации - (Саша Гольдштейн - CodeProject)
Оптимизация Jit: Inlining I (Дэвид Нотарио)
Оптимизация Jit: Inlining II (Дэвид Нотарио)

Если честно, вам не стоит слишком беспокоиться об этом уровне микродетали. Пусть компилятор / JIT'er позаботится об этом за вас, это лучше, чем вы, почти во всех случаях. Не зацикливайтесь на Преждевременная оптимизация . Сосредоточьтесь на том, чтобы заставить ваш код работать, а потом позаботьтесь об оптимизации, если (а) он не работает достаточно быстро, (б) у вас проблемы с размером.

Answer 2

Если вы беспокоитесь о производительности, запустите профилировщик. Затем изменить код. Скорее всего, за миллион лет вы никогда не угадаете на 100% правильно, куда идет время. Вы могли бы изменить время 0,02% и оставить метод, который вносит 62% бремени. Вы могли бы также сделать это хуже. Без профилировщика и доказательств ты слепой.

---

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

«Подъем» все еще имеет место, и все еще может достичь экономии , если код вызывается повторно в узком цикле; например:

var count = list.Count;
for(int i = 0 ; i < count ; i++) {...}

(забудьте о дискуссии for против foreach из вышесказанного - это ортогональное обсуждение). В вышеизложенном «подъемник» поможет производительности. Но просто чтобы быть действительно сбивающим с толку - с массивами, это наоборот, и более эффективно не поднять это:

for(int i = 0 ; i < arr.Length ; i++) {...}

JIT распознает это и снимает проверку границ (так как массивы имеют фиксированный размер).

Answer 3

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

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

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

Answer 4

Наиболее мощная оптимизация, выполняемая JIT, обычно встроенная. JIT может даже встроить сотни функций (я слышал эту цифру для JikesRVM). Они даже встроят вещи, которые не всегда возможно встроить, и обратят их позже, если потребуется (динамическая деоптимизация).

Хороший обзор: http://java.sun.com/products/hotspot/docs/whitepaper/Java_Hotspot_v1.4.1/Java_HSpot_WP_v1.4.1_1002_4.html.

По вашему конкретному вопросу, я бы сказал, вероятно, если рассматриваемый вызов функции горячий .