Я могу проверить, встроил ли компилятор C# вызов метода?
У меня была эта проблема как неудачная сборка в Azure, когда она была развернута из Git.
Оказывается, мой .gitignore исключает папку build из ..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0\build\net46\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props.
После того, как папка build была (сила) передана Git, проблема была решена.
8 ответов
Нет Вы не можете. Еще больше тот, который выбирает встраивание, не является компилятором VS, который берет Вас, кодируют, и преобразовывает его в IL, но JIT-компилятор, который берет IL и преобразовывает его в машинный код. Это вызвано тем, что только JIT-компилятор знает достаточно об архитектуре процессора, чтобы решить, если помещение встроенного метода является соответствующим как it’s компромисс между конвейерной обработкой инструкции и размером кэша.
Поэтому даже взгляд в Отражателе.NET не поможет Вам.
"Можно проверить Систему. Отражение. MethodBase. GetCurrentMethod ().Name. Если метод будет встроен, то он возвратит имя вызывающей стороны вместо этого".
Нет, Вы не можете.
В основном, Вы не можете сделать этого в большинстве современных компиляторов C++ также. inline просто предложение компилятору. Это свободно взять его или нет.
компилятор C# не делает никакого специального встраивания на уровне IL. Оптимизатор JIT является тем, который сделает это.
Знайте что отличающиеся работы Xbox.
А Google поднял это:
"Встроенный метод, который смягчает издержки вызова метода. JIT формирует во встроенное, что выполняет следующие условия.
- размер кода IL составляет 16 байтов или меньше.
- команда ответвления не используется (если предложение и т.д.).
- локальная переменная не используется.
- Обработка исключений не была выполнена (попытка, выгода, и т.д.).
- плавание не используется в качестве значения аргумента или возвращаемого значения метода (вероятно, Xbox 360, не примененным).
- , Когда два или больше аргумента находятся в методе, он использует для объявленного поворота.
Однако виртуальная функция не формируется во встроенное".
http://xnafever.blogspot.com/2008/07/inline-method-by-xna-on-xbox360.html
я понятия не имею, корректен ли он. Кто-либо?
Единственный способ проверить это состоит в том, чтобы получить или записать профилировщику и рычагу в события JIT, необходимо также удостовериться, Встроив, не выключен, как это по умолчанию при профилировании.
почему бы не использовать небезопасный код (встраивают c как ее известное) и используют c/c ++ указатели стиля, это безопасно от GC (т.е. не затронутое набором), но идет с его собственными последствиями безопасности (использование наклона для интернет-приложений зоны), но превосходно для вида вещи, кажется, что Вы пытаетесь достигнуть особенно с производительностью и еще больше с массивами и битовыми операциями?
для подведения итогов Вы хотите производительность для небольшой части Вашего приложения? используйте небезопасный код и используйте указатели, и т.д. кажется наилучшим вариантом мне
РЕДАКТИРОВАНИЕ: немного начинающий? http://msdn.microsoft.com/en-us/library/aa288474 (По сравнению с 71) .aspx
Можно обнаружить его во времени выполнения с вышеупомянутым вызовом GetCurrentMethod. Но, это, казалось бы, было бы чем-то вроде отходов [1]. Самая легкая вещь сделать была бы только к ILDASM MSIL и проверка там.
Примечание, что это специально для компилятор встраивание вызова и покрыто различным Отражение документы о MSDN.
, Если метод, который называет метод GetCallingAssembly, расширен встроенный компилятором (то есть, если компилятор вставляет тело функции на испускаемый промежуточный язык Microsoft (MSIL), вместо того, чтобы испустить вызов функции), то блок, возвращенный методом GetCallingAssembly, является блоком, содержащим встроенный код. Это могло бы отличаться от блока, который содержит исходный метод. Чтобы гарантировать, что метод, который называет метод GetCallingAssembly, не встраивается компилятором, можно применить атрибут MethodImplAttribute с MethodImplOptions. NoInlining.
Однако Дрожание также свободно встроить вызовы - но я думаю, что дизассемблер был бы единственным способом проверить то, что и не сделано на том уровне.
Редактирование: Только для разрешения некоторого беспорядка в этом потоке csc.exe будет встроенные вызовы MSIL - хотя Дрожание (вероятно), будет более агрессивно в нем.
[1] И, отходами - я подразумеваю, что (a) это это побеждает цель встраивания (лучшая производительность) из-за Отражательного поиска. И (b), это, вероятно, изменило бы поведение встраивания так, чтобы это больше не встраивалось так или иначе. И, прежде чем Вы думаете, что можно просто повернуться, это на Отладке создает с Утверждением, или что-то - понимает, что не будет встроено во время Отладки, но может быть в Выпуске.
там способ вынудить компилятор встроить этот вызов, или я сделаю, я просто надеюсь, что компилятор сделает эту оптимизацию?
, Если более дешево встроить функцию, это будет. Не волнуйтесь об этом, если Ваш профилировщик не говорит, что это на самом деле - проблема.
Для получения дополнительной информации