Компактный каркас и JIT. Сколько времени это может занять - PullRequest
Новая
       10

Компактный каркас и JIT. Сколько времени это может занять

2 голосов
/ 20 января 2009

В нашем приложении произошла фантомная задержка. Это было связано с инициализацией синглтона, когда объект был впервые затронут и обвинен в JIT. Я не полностью убежден в этом, поскольку нет механизма для измерения JIT (или есть?), И вся задержка составляла семь секунд. Семь секунд JIT?!? Может ли это быть на самом деле?

В любом случае, мне трудно обвинять вещи, которые трудно измерить. Когда я взглянул на эту проблему некоторое время назад, я закомментировал кучу кода и наблюдал, как «скачок» в течение семи секунд в другом месте приложения. Предполагая, что это каким-то образом происходит в фоновом процессе где-то (и я думаю, что это будет учитывать JIT в качестве потенциальной причины).

Просто для забавы, если был статический объект, который ссылался на множество других объектов, есть ли у кого-нибудь эмпирическое правило, сколько времени может занять JIT? У кого-нибудь есть дальнейшие ссылки, чтобы я мог больше понять о JIT, чтобы у меня была возможность узнать, виноват ли JIT в этом замедлении или нет?

Ответы [ 2 ]

1 голос
/ 20 января 2009

JIT (и GC) таймеры и т. Д. Можно найти здесь:

Счетчики производительности в .NET Compact Framework (http://msdn.microsoft.com/en-us/library/ms172525.aspx)

Мониторинг производительности приложений в .NET Compact Framework, часть I - включение счетчиков производительности (http://blogs.msdn.com/davidklinems/archive/2005/10/04/476988.aspx)

Анализ производительности приложений устройства с помощью удаленного монитора производительности .Net Compact Framework (http://blogs.msdn.com/stevenpr/archive/2006/04/17/577636.aspx)

Счетчики производительности в .NET Framework
(http://msdn.microsoft.com/en-us/library/w8f5kw2e(VS.80).aspx)

С уважением, Тамберг

1 голос
/ 20 января 2009

Я только видел, как JIT занимал очень много времени (больше 1 секунды) в странной ошибке, связанной с шаблонными элементами внутри шаблонной коллекции (см. Правку ниже).

Во всяком случае, тот факт, что вы видите это «движение», определенно указывает мне, что, вероятно, это не проблема. Чтобы попытаться определить это окончательно, я бы посмотрел на использование RPM, чтобы увидеть, что происходит прямо до и после задержки.

Ожидаемое время JIT - это действительно туманная вещь, так как на это может влиять так много факторов. Скорость процессора очевидна, но менее очевидными могут быть такие вещи, как носители данных приложений и нагрузка на память устройства.

Носители данных могут влиять на скорость JIT, потому что JITter должен извлекать IL из носителя, когда ему нужно JIT, и, если его вытягивать медленно, то JITting будет медленным.

Давление памяти является серьезным и может иметь серьезные последствия для устройства CE. Проблема здесь в том, что когда вы начинаете исчерпывать память, EE начинает передавать код JITted во время сбора - все, кроме стека вызовов. Теперь, если вы находитесь в подпрограмме, которая, например, вызывает какой-то рабочий или вспомогательный материал или у него запущен поток, тогда этот вспомогательный метод может получать Pitch, JITted, Pitch JITted и т.д. Это называется трэш ".

Определить последнее довольно просто с помощью RPM (исправить это может быть не так просто). Посмотрите на количество кода, часто используемого для поднятия, и найдите сильную корреляцию между увеличением числа шагов и вашими предполагаемыми блокировками.

Редактировать: Я наконец нашел описание ошибки здесь .

...