Есть ли обходной путь для ограничения времени встраивания C # 28?

Я работаю над оптимизацией программы моделирования физики с помощью профилировщика производительности Red Gate. public int Count {get {return count; }} Это вызвало огромный скачок производительности, и мне потребовалось значительное время, чтобы обнаружить, что, когда cell.Count появлялся в методе 28 или менее раз, он был встроен каждый раз, но как только cell.Count появлялся в методе 29 или более раз , он ни разу не был встроен (даже несмотря на то, что подавляющее большинство вызовов были из частей кода худшего сценария, которые выполнялись редко.)

Итак, возвращаясь к моему вопросу, есть ли у кого-нибудь идеи, чтобы обойти это предел? Я думаю, что простое решение - просто сделать поле count внутренним, а не частным, но мне хотелось бы лучшего решения, чем это, или, по крайней мере, просто лучшего понимания ситуации. Я бы хотел, чтобы подобные вещи упоминались на странице Microsoft «Написание высокопроизводительных управляемых приложений» по адресу http://msdn.microsoft.com/en-us/library/ms973858. aspx , но, к сожалению, это не так (возможно, из-за того, насколько произвольным является ограничение в 28 счетчиков?)

Я использую .NET 4.0.

РЕДАКТИРОВАТЬ: Похоже, я неправильно истолковал свое небольшое тестирование. Я обнаружил, что сбой встраивания был вызван не тем, что сами методы вызывались более 28 раз, а потому, что метод, в который они должны быть встроены, "слишком длинный" по некоторым стандартам. Это все еще сбивает меня с толку, потому что я не понимаю, как простой получатель может быть рационально не встроен (и производительность значительно выше с ними, как мне ясно показывает мой профилировщик), но, очевидно, компилятор CLI JIT отказывается встраивать что-либо только потому, метод уже большой (игра с небольшими вариациями показала мне, что этот предел - это размер кода (из idasm) 1500, выше которого встраивание не выполняется, даже в случае моих геттеров, что некоторые тесты показали, что дополнительных накладных расходов кода для встраивания не требуется).

Спасибо.