Там какой-либо путь состоит в том, чтобы изменить JIT-компилятор.NET для одобрения производительности за время компиляции?
Похоже, PostsService.getPosts() возвращает void вместо Post[].
Так что, пожалуйста, проверьте это в вашем PostsService классе.
Это должно выглядеть так:
getPosts(): Post[] {
// implementation
}
1 ответ
Это установлено при компиляции блока. Существует два типа оптимизации:
- оптимизация IL
- качество Собственного кода JIT.
настройка по умолчанию - это
/optimize- /debug-
, Это означает неоптимизированный IL и оптимизированный собственный код.
/optimize /debug(+/full/pdbonly)
Это означает неоптимизированный IL и неоптимизированный собственный код (лучшие параметры настройки отладки).
Наконец, для получения самой быстрой производительности:
/optimize+ /debug(-/+/full/pdbonly)
Это производит оптимизированный IL и оптимизированный собственный код.
При создании неоптимизированного IL, компилятор вставит инструкции по NOP на всем протяжении кода. Это делает код легче отладить, позволяя точкам останова быть установленным на инструкциях по потоку управления таких что касается, в то время как, если, еще, попытка, выгода и т.д.
CLR делает удивительно хорошее задание оптимизации кода независимо. После того как метод является JIT'ed, на указатель на вызове или callvirt инструкции указывают непосредственно на собственный код.
Кроме того, CLR использует в своих интересах любые приемы архитектуры, доступные когда JIT'ing Ваш код. Это означает, что блок пробежал JIT, будет работать быстрее, чем блок, предварительно скомпилированный при помощи Ngen (хотя с немного более медленным временем запуска), поскольку NGen скомпилирует для всех платформ и не использует в своих интересах любые приемы.