Почему traceview дает непоследовательные измерения?
Я пытаюсь ускорить запуск моего приложения (в настоящее время ~5 секунд из-за медленной привязки Guice), и когда я запускаю трассировку, я вижу довольно большие вариации (до 30%) в измерениях при выполнении того же самого код.
Я предполагаю, что это из-за различий в сборке мусора, но время, потраченное на startGC согласно traceview совершенно незначительно.
Это особенно усугубляет, потому что очень трудно определить, каковы были результаты моих оптимизаций, когда измерения настолько изменчивы.
Почему это происходит? Есть ли способ сделать измерения более последовательными?
3 ответа
Если вы выполняете какие-либо действия, связанные с сетью, при запуске, этот инструмент может помочь вам понять, что происходит и как вы можете оптимизировать соединения и кэширование. http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312
Я полагаю, вы начинаете профилирование с кода, а не включаете его вручную? Но в любом случае, даже если вы используете Debug.startMethodTracing а также Debug.stopMethodTracing с определенной точки вашего кода вы получите различные измерения.
Здесь вы можете видеть, что Traceview отключает JIT, и я считаю, что некоторые другие оптимизации, поэтому во время профилирования ваш код выполняется медленнее, чем без него. Также производительность вашего кода зависит от общей загрузки системы. Если какое-то другое приложение выполняет какие-либо тяжелые операции в фоновом режиме, ваш код будет выполняться дольше. Таким образом, вы определенно должны получить результаты, которые немного отличаются и поэтому время запуска не может быть постоянным.
Как правило, не так важно, как долго выполняется ваш метод, но сколько процессорного времени он потребляет по сравнению с другими методами.
Похоже, измерение не ваша конечная цель. Ваша конечная цель - сделать это быстрее.
Способ сделать это - найти, какие действия занимают большую долю времени, чтобы вы могли найти лучший способ их выполнения. Я сказал "находка", а не "измерение", и я сказал "деятельность", а не "рутина".
Для этого нужно только отобрать состояние программы. Многие профилировщики собирают большое количество выборок состояния программы, но затем все они попадают в одну и ту же логику - они обобщают теорию о том, что все, что вам нужно, это измерения, а вам на самом деле все равно, что.
На самом деле, если вместо того, чтобы получать резюме, вы могли бы детально изучить некоторые из примеров, это намного больше расскажет вам о том, как программа тратит свое время.
Более того, если всего за два (2) примера вы увидите, что программа преследует какую-то цель, и это было чем-то, что вы могли бы значительно улучшить, вы бы увидели значительное ускорение. Этот процесс можно повторить несколько раз, и именно так вы можете его оптимизировать.
Процесс объясняется более подробно здесь, и здесь есть пример использования.