Что плохого в использованиe в MethodImpl(MethodImplOptions.AggressiveOptimization)?

Question

[Popou]

Решил я значит поиграть со слабыми ссылками:

var mc = new ManagedClass();

var wr = new WeakReference(mc);

Console.WriteLine(wr.Target ?? "not exist");
mc = null;
GC.Collect();
Console.WriteLine(wr.Target ?? "not exist");

Если добавить атрибут то выйдет следующий результат:

ManagedClass
not exist

Если же нет:

ManagedClass
ManagedClass

И вот вопрос, почему MethodImpl(MethodImplOptions.AggressiveOptimization) не установлен везде по умолчанию? Ведь все по итогу работает так как, и ожидалось: если на объект нет ссылки то GC его удаляет, если есть то не трогает.

Comments

[Kano]

Если сделать его обязательным для всех методов то это пртведёт к увеличению времени запуска и увелтчению потребляемой памяти т.к. jit компилятору придется компилировать код в наиболее эффективный, а это временные затраты. Также коду придеётся вызвать все статические конструкторы, даже если они не будут использованы.

Jit компиляцию можно избежать если публиковать сборку в режиме readytorun, но тогда мы получим бинарник только под одну конкретную платформу

Answer 1

[Сергей Соловьев]

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

В итоге: никто не запрещает его везде использовать, просто это "Экономически" не выгодно

Answer 2

[Василий Банников]

Плохо тем что JIT будет нагружаться лишний раз там, где это не требуется.
Лучше этим атрибутом помечать только очевидные hot path.
Аналогично с агрессивным инлайнингом - только с ним ещё страшнее.