Я только видел, как JIT занимал очень много времени (больше 1 секунды) в странной ошибке, связанной с шаблонными элементами внутри шаблонной коллекции (см. Правку ниже).
Во всяком случае, тот факт, что вы видите это «движение», определенно указывает мне, что, вероятно, это не проблема. Чтобы попытаться определить это окончательно, я бы посмотрел на использование RPM, чтобы увидеть, что происходит прямо до и после задержки.
Ожидаемое время JIT - это действительно туманная вещь, так как на это может влиять так много факторов. Скорость процессора очевидна, но менее очевидными могут быть такие вещи, как носители данных приложений и нагрузка на память устройства.
Носители данных могут влиять на скорость JIT, потому что JITter должен извлекать IL из носителя, когда ему нужно JIT, и, если его вытягивать медленно, то JITting будет медленным.
Давление памяти является серьезным и может иметь серьезные последствия для устройства CE. Проблема здесь в том, что когда вы начинаете исчерпывать память, EE начинает передавать код JITted во время сбора - все, кроме стека вызовов. Теперь, если вы находитесь в подпрограмме, которая, например, вызывает какой-то рабочий или вспомогательный материал или у него запущен поток, тогда этот вспомогательный метод может получать Pitch, JITted, Pitch JITted и т.д. Это называется трэш ".
Определить последнее довольно просто с помощью RPM (исправить это может быть не так просто). Посмотрите на количество кода, часто используемого для поднятия, и найдите сильную корреляцию между увеличением числа шагов и вашими предполагаемыми блокировками.
Редактировать: Я наконец нашел описание ошибки здесь .