Когда начинать использовать IL на более высоких языках

Question

После просмотра нескольких проектов с открытым исходным кодом, большинство из которых были разработаны командой обмена стека. Я заметил, что несколько раз они просто пишут прямой код IL, встроенный в функцию C#.

Прекрасный пример, который вы можете увидеть в файле Dapper.

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

Мое любопытство заключается в том, когда решение начать использовать эмиттер IL по сравнению с обычным старым C#?

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

Answer 1

.NET IL настолько прост по сравнению с реальными языками ассемблера ЦП (x86 и т. Д.), Что есть только один способ сделать практически все. Это означает, что вы не можете достичь лучшей производительности с лучшим IL, потому что лучшего IL нет. (Предположим, что вы не генерируете субоптимальный IL преднамеренно, что делает отладочная сборка.)

Производительность.NET во многом зависит от JIT-тер. Во всяком случае, вся идея языка высокого уровня, JIT-Ting, GC-ING, и т. Д. имеет свои показатели производительности, поэтому небольшие оптимизации в IL в любом случае не имеют большого значения.

Так почему люди используют IL? Это когда вы генерируете код (например, когда вы компилируете XSLT, регулярное выражение или динамический прокси). Это намного быстрее сделать в IL, чем создавать код C# в строковом буфере и компилировать его, и все.

Помимо способности генерировать код на лету, когда IL необходим, я не верю, что у IL есть и другие преимущества. C# - это такой многофункциональный и быстро развивающийся язык, что было бы просто безумно, если бы его не использовали. Работа в IL была бы наказанием. Вы можете быть уверены, что C# может быть скомпилирован в максимально хороший IL.

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

И, кстати, AFAIK вы не можете встраивать IL внутри файла C#. Помимо создания нового кода на лету, вы не можете скомпилировать IL в свою сборку, по крайней мере, не в Visual Studio, за исключением некоторых приемов, связанных с изменением сборок после их сборки из C#.