FSharp.Core не оптимизирован?

Question

Я недавно проверил производительность приложения F # и, копаясь в CIL, я обнаружил, что FSharp.Core (для .NET v4.0) содержит несколько инструкций nop, много неиспользуемых переменных и только переменные записывается / читается один раз с помощью последовательностей инструкций stloc / ldloc.
Я исследовал возможные причины и заметил, что даже в режиме релиза сборки F # включают директиву --debug: pdbonly, и невозможно отключить это и переключиться на --debug- из пользовательского интерфейса настроек проекта.
Мне интересно, был ли конкретный выбор для настроек компиляции FSharp.Core и если да, то что это было. В противном случае законно ли ожидать полностью оптимизированную версию среды выполнения?

Answer 1

Кажется, что комментарии на вопрос уже ответили о 90% этого; повторить их:

• почти каждый двоичный файл релиза во вселенной компилируется с --debug: pdbonly
• , даже если код IL неоптимален, это может не иметь никакого реального влияния из-за оптимизации JIT

Есть, конечно, всевозможные способы, которыми компилятор F # мог бы потенциально генерировать лучший код (это, вероятно, верно для каждого компилятора); если вы профилируете свое приложение и заметите что-то плохое (например, большое несоответствие и сопоставимый код из C #), тогда вы можете сообщить об этом команде F #, отправив fsbugs. Но сначала измерить.

Answer 2

В противном случае законно ли ожидать полностью оптимизированную версию среды выполнения?

Изменения, которые вы предлагаете, не могут обоснованно рассматриваться как оптимизация. Оба безвредны и будут компилироваться виртуальной машиной. ISTR, мутация используется для замены стеков, потому что основанная на стеке виртуальная машина может переполнять стек. Так что F # корректно работает над ошибкой в ​​CLR.