Performance/Fenix/Profilers and Tools - Revision history

Mcomella: /* Advanced tools: */ Add perfetto

2022-11-14T20:52:34Z

Advanced tools:: Add perfetto

← Older revision		Revision as of 20:52, 14 November 2022
Line 31:		Line 31:

	<ol>		<ol>
			<li>'''Perfetto''' ([https://ui.perfetto.dev/ official documentation]) is a comprehensive tracing profiler developed by Google for Android, Chrome, and other applications. It uses many Linux profiling facilities to get information about the application as well as OS-level information (e.g. which CPU is scheduled, what's the frequency, how does disk IO look, etc.). We haven't explored this thoroughly but it seems useful and is easy to run on modern Android devices</li>
	<li>'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you want:		<li>'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you want:
	<ol>		<ol>

Mcomella: Mcomella moved page Performance/Fenix/Getting Started to Performance/Fenix/Profilers and Tools: Original page title is not descriptive to content

2021-08-17T16:15:55Z

Mcomella moved page Performance/Fenix/Getting Started to Performance/Fenix/Profilers and Tools: Original page title is not descriptive to content

← Older revision	Revision as of 16:15, 17 August 2021
(No difference)

Mcomella: /* Profilers and performance tooling */ update with current knowledge

2021-05-07T17:57:36Z

Profilers and performance tooling: update with current knowledge

← Older revision		Revision as of 17:57, 7 May 2021
Line 20:		Line 20:
	</ol>		</ol>
	</li>		</li>
	<li>The '''~~Android Profiler~~''' ([https://developer.android.com/~~studio~~/~~profile~~/~~android-profiler~~/~~?gclid=EAIaIQobChMImNycnqrf6gIVUfDACh3PWQe6EAAYASAAEgIb6_D_BwE&gclsrc=aw~~.ds documentation]) is most useful when you:		<li>The '''Debug''' API ([https://developer.android.com/reference/android/os/Debug#startMethodTracingSampling(java.lang.String,%20int,%20int) documentation]) is most useful when you:
	<ol>		<ol>
	<li> Need access to Java threads other than the main thread </li>		<li> Need access to Java threads other than the main thread </li>
	<li> Are profiling application start up and want to capture it as early ~~as possible~~ </li>		<li> Are profiling application start up and want to capture it early (when the application can start executing code)</li>
	</ol> The results in the Android Profiler are '''very misleading''': what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently ([https://youtu.be/ZffMCJdA5Qc?t=631 further explanation]). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.		</ol> The profiles have non-trivial overhead (a few hundred ms in a 1.5-2.5s start up) and seem to be more representative than the Android Profiler. See [[Performance/Fenix/Debug API]] for a how-to guide on usage in Firefox.
			<li>The '''Android Profiler''' ([https://developer.android.com/studio/profile/android-profiler/?gclid=EAIaIQobChMImNycnqrf6gIVUfDACh3PWQe6EAAYASAAEgIb6_D_BwE&gclsrc=aw.ds documentation]) is most useful when you want the benefits of the `Debug` API but cannot instrument the code. The results in the Android Profiler are '''very misleading''': what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently ([https://youtu.be/ZffMCJdA5Qc?t=631 further explanation]). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.
	</li>		</li>
	</ol>		</ol>
Line 30:		Line 31:

	<ol>		<ol>
	<li>'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you:		<li>'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you want:
	<ol>		<ol>
	<li> ~~Need access to Java threads other than~~ the ~~main thread~~</li>		<li>The benefits of the Debug API</li>
	<li> ~~Are profiling application~~ start up ~~and want to~~ capture ~~it as early as possible~~ </li>		<li>To capture the start up trace even earlier (at process start)</li>
	</ol>~~This is a good alternative~~ to ~~the AS profiler since it has a much lower~~ overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.		<li>To capture native traces</li>
	</li>		</ol>
			It appears to have low overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.
			</li>
	<li>'''Nanoscope''' is another tool that can be useful to profile non-debuggable applications. ([https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps documentation]). We would only suggest to use this tool whenever profiling start up has failed with the previous options.		<li>'''Nanoscope''' is another tool that can be useful to profile non-debuggable applications. ([https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps documentation]). We would only suggest to use this tool whenever profiling start up has failed with the previous options.
	</li>		</li>

Mcomella: Mcomella moved page Performance/How to get started on Fenix to Performance/Fenix/Getting Started: Better hierarchy

2021-05-07T17:39:26Z

Mcomella moved page Performance/How to get started on Fenix to Performance/Fenix/Getting Started: Better hierarchy

← Older revision	Revision as of 17:39, 7 May 2021
(No difference)

Mcomella: /* Profilers and performance tooling */ WARNING -> important note

2020-08-21T19:51:36Z

Profilers and performance tooling: WARNING -> important note

← Older revision		Revision as of 19:51, 21 August 2020
Line 8:		Line 8:
	==Profilers and performance tooling==		==Profilers and performance tooling==

	'''~~WARNING~~: ~~This~~ approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see [[#Timestamp measurement\|timestamp measurement]] or [[#Performance tests\|performance tests]].		'''Important note: this approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see [[#Timestamp measurement\|timestamp measurement]] or [[#Performance tests\|performance tests]].
	'''		'''

Mcomella: /* Profilers and performance tooling */ Link sections in warning

2020-08-21T19:50:53Z

Profilers and performance tooling: Link sections in warning

← Older revision		Revision as of 19:50, 21 August 2020
Line 8:		Line 8:
	==Profilers and performance tooling==		==Profilers and performance tooling==

	'''WARNING: This approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see timestamp measurement or performance tests ~~[LINK ME!~~].		'''WARNING: This approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see [[#Timestamp measurement\|timestamp measurement]] or [[#Performance tests\|performance tests]].
	'''		'''

Mcomella: Link to section headers

2020-08-21T19:50:06Z

Link to section headers

← Older revision		Revision as of 19:50, 21 August 2020
Line 1:		Line 1:
	Measuring performance has a few major approaches:		Measuring performance has a few major approaches:
	* Profilers and performance tooling: detailed info with some overhead		* [[#Profilers and performance tooling\|Profilers and performance tooling:]] detailed info with some overhead
	* Timestamp measurement: precise values with no details		* [[#Timestamp measurement\|Timestamp measurement:]] precise values with no details
	* Performance tests: ~~NOT READY~~		* [[#Performance tests\|Performance tests:]] a WIP

	If you need more assistance with android performance testing, please reach out to us on the [https://chat.mozilla.org/#/room/#perf-android-frontend:mozilla.org #perf-android-frontend channel on Matrix].		If you need more assistance with android performance testing, please reach out to us on the [https://chat.mozilla.org/#/room/#perf-android-frontend:mozilla.org #perf-android-frontend channel on Matrix].
Line 47:		Line 47:
	* Use a production build variant: see the [https://github.com/mozilla-mobile/fenix/blob/master/README.md#guide-to-build-variants guide on build variants in the Fenix README]		* Use a production build variant: see the [https://github.com/mozilla-mobile/fenix/blob/master/README.md#guide-to-build-variants guide on build variants in the Fenix README]
	* If you’re measuring UI, you may need to measure when frames are drawn, not when lifecycle methods (e.g. onResume) are called		* If you’re measuring UI, you may need to measure when frames are drawn, not when lifecycle methods (e.g. onResume) are called

			== Performance tests ==
			These aren't ready for broader use yet – please contact us for questions!

Mleclair: Edited lists to be more readable.

2020-08-14T20:07:40Z

Edited lists to be more readable.

← Older revision		Revision as of 20:07, 14 August 2020
Line 13:		Line 13:
	There are different tools at your disposal. Each of them has a specific use case and the details are below.		There are different tools at your disposal. Each of them has a specific use case and the details are below.

	# The '''Firefox Profiler / Gecko Profiler''' ([https://profiler.firefox.com/docs/#/./guide-remote-profiling documentation]) is the preferred profiler. This profiler allows us to profile the code with lower overhead and non-debuggable builds including APKs from the Play Store, capture native code, and share profiles right in the browser. The UX is just so much better. :) You should try another profiler if you:		<ol>
	## Need access to Java threads other than the main thread (issue )		<li>The '''Firefox Profiler / Gecko Profiler''' ([https://profiler.firefox.com/docs/#/./guide-remote-profiling documentation]) is the preferred profiler. This profiler allows us to profile the code with lower overhead and non-debuggable builds including APKs from the Play Store, capture native code, and share profiles right in the browser. The UX is just so much better. :) You should try another profiler if you:
	## Are profiling application start up and some information is missing ([https://bugzilla.mozilla.org/show_bug.cgi?id=1659103 bug 1659103])		<ol>
	#The '''Android Profiler''' ([https://developer.android.com/studio/profile/android-profiler/?gclid=EAIaIQobChMImNycnqrf6gIVUfDACh3PWQe6EAAYASAAEgIb6_D_BwE&gclsrc=aw.ds documentation]) is most useful when you:		<li>Need access to Java threads other than the main thread (issue )</li>
	##Need access to Java threads other than the main thread		<li>Are profiling application start up and some information is missing ([https://bugzilla.mozilla.org/show_bug.cgi?id=1659103 bug 1659103])</li>
	##Are profiling application start up and want to capture it as early as possible		</ol>
	#: The results in the Android Profiler are '''very misleading''': what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently ([https://youtu.be/ZffMCJdA5Qc?t=631 further explanation]). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.		</li>
			<li>The '''Android Profiler''' ([https://developer.android.com/studio/profile/android-profiler/?gclid=EAIaIQobChMImNycnqrf6gIVUfDACh3PWQe6EAAYASAAEgIb6_D_BwE&gclsrc=aw.ds documentation]) is most useful when you:
			<ol>
			<li> Need access to Java threads other than the main thread </li>
			<li> Are profiling application start up and want to capture it as early as possible </li>
			</ol> The results in the Android Profiler are '''very misleading''': what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently ([https://youtu.be/ZffMCJdA5Qc?t=631 further explanation]). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.
			</li>
			</ol>
	=== Advanced tools: ===		=== Advanced tools: ===
	#'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you:
	##Need access to Java threads other than the main thread		<ol>
	##Are profiling application start up and want to capture it as early as possible		<li>'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you:
	#:This is a good alternative to the AS profiler since it has a much lower overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.		<ol>
	#'''Nanoscope''' is another tool that can be useful to profile non-debuggable applications. ([https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps documentation]). We would only suggest to use this tool whenever profiling start up has failed with the previous options.		<li> Need access to Java threads other than the main thread</li>
			<li> Are profiling application start up and want to capture it as early as possible </li>
			</ol>This is a good alternative to the AS profiler since it has a much lower overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.
			</li>
			<li>'''Nanoscope''' is another tool that can be useful to profile non-debuggable applications. ([https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps documentation]). We would only suggest to use this tool whenever profiling start up has failed with the previous options.
			</li>
			</ol>

	== Timestamp measurement ==		== Timestamp measurement ==

Mleclair: A quick guide to analyze performance on Fenix

2020-08-14T20:01:51Z

A quick guide to analyze performance on Fenix

New page

Measuring performance has a few major approaches:
* Profilers and performance tooling: detailed info with some overhead
* Timestamp measurement: precise values with no details
* Performance tests: NOT READY

If you need more assistance with android performance testing, please reach out to us on the [https://chat.mozilla.org/#/room/#perf-android-frontend:mozilla.org #perf-android-frontend channel on Matrix].

==Profilers and performance tooling==

'''WARNING: This approach will create overhead and give less accurate time values. This method is useful when you are looking for red flags in your code and trying to diagnose performance issues. If you want accurate measurements, see timestamp measurement or performance tests [LINK ME!].
'''

There are different tools at your disposal. Each of them has a specific use case and the details are below.

# The '''Firefox Profiler / Gecko Profiler''' ([https://profiler.firefox.com/docs/#/./guide-remote-profiling documentation]) is the preferred profiler. This profiler allows us to profile the code with lower overhead and non-debuggable builds including APKs from the Play Store, capture native code, and share profiles right in the browser. The UX is just so much better. :) You should try another profiler if you:
## Need access to Java threads other than the main thread (issue )
## Are profiling application start up and some information is missing ([https://bugzilla.mozilla.org/show_bug.cgi?id=1659103 bug 1659103])
#The '''Android Profiler''' ([https://developer.android.com/studio/profile/android-profiler/?gclid=EAIaIQobChMImNycnqrf6gIVUfDACh3PWQe6EAAYASAAEgIb6_D_BwE&gclsrc=aw.ds documentation]) is most useful when you:
##Need access to Java threads other than the main thread
##Are profiling application start up and want to capture it as early as possible
#: The results in the Android Profiler are '''very misleading''': what you see in profiles may not accurately represent what users’ experience in release builds. This is due to the debuggable=true requirement which causes different methods to increase in runtime inconsistently ([https://youtu.be/ZffMCJdA5Qc?t=631 further explanation]). For example, in the AS Profiler, we’ve seen that UI layout is proportionally longer than business logic than in production builds.
=== Advanced tools: ===
#'''Simpleperf''' ([https://android.googlesource.com/platform/system/extras/+/master/simpleperf/doc/README.md#Android-application-profiling official documentation]; follow the Fenix-specific steps found in this [https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps README]) is most useful when you:
##Need access to Java threads other than the main thread
##Are profiling application start up and want to capture it as early as possible
#:This is a good alternative to the AS profiler since it has a much lower overhead. However, it’s difficult to set up and will only be able to profile start up with rooted phones.
#'''Nanoscope''' is another tool that can be useful to profile non-debuggable applications. ([https://github.com/acreskeyMoz/simpleperf_for_geckoview_example#simpleperf-for-gecko-apps documentation]). We would only suggest to use this tool whenever profiling start up has failed with the previous options.

== Timestamp measurement ==
In order to have a precise understanding of the impact of your changes on performance, you need to measure what the user experiences with little overhead. In practice, this is done by instrumenting your code with timestamps and outputting to Logcat. Measuring your changes can go wrong in many ways, so please reach out to us at [https://chat.mozilla.org/#/room/#perf-android-frontend:mozilla.org #perf-android-frontend on Matrix] so that we can explain what to look out for.

If you decide to jump in anyway, you’ll need to:
* Use [https://developer.android.com/reference/android/os/SystemClock#elapsedRealtime() SystemClock.elapsedRealtime] to measure timestamps
* Use a production build variant: see the [https://github.com/mozilla-mobile/fenix/blob/master/README.md#guide-to-build-variants guide on build variants in the Fenix README]
* If you’re measuring UI, you may need to measure when frames are drawn, not when lifecycle methods (e.g. onResume) are called