Почему traceview дает непоследовательные измерения?

1

Я пытаюсь ускорить время запуска своего приложения (в настоящее время ~ 5 секунд из-за медленной привязки Guice), и когда я запускаю traceview, я вижу довольно большие вариации (до 30%) в измерениях от выполнения тех же код.

Я бы предположил, что это из-за различий в сборке мусора, но время, потраченное в startGC соответствии с трассировкой, совершенно незначителен.

Это особенно усугубляет ситуацию, потому что очень сложно определить, какие эффекты были для моих оптимизаций, когда измерения настолько переменны.

Почему это происходит? Есть ли способ сделать измерения более последовательными?

Теги:
profiling
android-traceview

3 ответа

0

Если вы выполняете какую-либо деятельность, связанную с сетью при запуске, этот инструмент может помочь вам понять, что происходит и как вы можете оптимизировать соединения и кеширование. http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312

0

Похоже, что измерение - это не ваша конечная цель. Ваша конечная цель - сделать это быстрее.

Способ сделать это - найти, какие виды деятельности составляют значительную часть времени, поэтому вы можете найти лучший способ их выполнения. Я сказал "нахождение", а не "измерение", и я сказал "деятельность", а не "подпрограммы".

Для этого необходимо только просмотреть состояние программы. Многие профилографы собирают большое количество образцов состояния программы, но тогда все они попадают в одну и ту же логику - они суммируют, по теории, что все, что вам нужно, это измерения, и вам на самом деле все равно.

На самом деле, если вы не можете получить резюме, вы можете подробно изучить некоторые образцы, это расскажет вам гораздо больше о том, как программа тратит свое время.

Что еще, если всего на двух (2) образцах вы могли видеть, что программа преследует какую-то цель, и вы могли бы значительно улучшить ситуацию, вы увидите значительное ускорение. Этот процесс можно повторить несколько раз и как вы можете его оптимизировать.

Процесс объясняется более подробно здесь есть и вариант использования здесь.

  • 0
    Интересно, но если я что-то упустил, это не поможет ответить на вопрос. Traceview уже дает полностью детерминированный подсчет и иерархию вызовов методов.
  • 0
    @Jeff: 1) Не ожидайте согласованности временных измерений. Существует слишком много неконтролируемых факторов, и это все равно не имеет значения. 2) Что касается количества вызовов и иерархии, проверьте вопросы здесь . Может показаться, что он говорит вам все, что вам нужно знать, но это не так.
0

Я полагаю, вы начинаете профилирование из кода, а не вручную его вручную? Но в любом случае, даже если вы используете Debug.startMethodTracing и Debug.stopMethodTracing из определенной точки вашего кода, вы получите различные измерения.

Вы можете видеть здесь, что Traceview отключает JIT, и я верю в некоторые другие оптимизации, поэтому при профилировании ваш код выполняется медленнее, чем без него. Кроме того, производительность вашего кода зависит от общей загрузки системы. Если какое-либо другое приложение выполняет тяжелую операцию в фоновом режиме, ваш код будет работать дольше. Таким образом, вы должны определенно получить результаты, которые немного отличаются и поэтому время запуска не может быть постоянным.

Как правило, не так важно, как долго длится ваш метод, но сколько процессорного времени он потребляет по сравнению с другими методами.

  • 0
    Я говорю об измерении времени процессора, что, конечно, является единственным метрическим трассировкой. Должно быть, я смутил вас упоминанием пятисекундного времени запуска (измеряемого с помощью секундомера без включенного профилирования) в качестве введения в мотивацию для профилирования. Так как же измерить с разумной согласованностью, сколько процессорного времени занимает запуск? И да, я использую Debug.start/stopMethodTracing
  • 0
    Я не думаю, что можно добиться большей согласованности, чем вы уже имеете. Если ваш процесс инициализации использует некоторые функции ввода-вывода для чтения данных, он уже не будет последовательным. Также я предполагаю, что ваш код выполняется в отдельном потоке, поэтому, если он выполняется в однопроцессорном режиме, результаты профилирования системы будут зависеть от планировщика системных потоков, потому что на самом деле ваш код не будет выполняться все это время непрерывно. Я почти уверен, что невозможно получить абсолютно одинаковые следы от разных запусков.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню