Profiling SpiderMonkey

  • Revision slug: SpiderMonkey/Profiling_SpiderMonkey
  • Revision title: Profiling SpiderMonkey
  • Revision id: 167580
  • Created:
  • Creator: Sheppy
  • Is current revision? No
  • Comment /* Instructions */

Revision Content

Instructions

1.) Get yourself an optimized libxul build of Firefox, with debugger info.

For the Mac, you'll want to read up on Profiling JavaScript with Shark. Here's a sample mozconfig:

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-libxul
mk_add_options MOZ_MAKE_FLAGS=-j3
ac_add_options --enable-optimize
ac_add_options --enable-libxul
ac_add_options --enable-shark
ac_add_options --enable-debugger-info-modules
ac_add_options --enable-application=browser

2.) You'll want to run Shark on both the browser and [xpcshell], since the host environments differ. Here are some instrumented tests to work from: media:Profiling-ammo.zip

3.) Once you have some changes you'd like try, you can just rebuild the js/src directory, since it produces its own shared library, even in libxul and static builds.

make -C my-obj-dir/js/src

Other Ways To Profile

For Linux, there are global jprof functions available. See the documentation on the --enable-jprof mozconfig option. We're working to add support for other profilers, such as OProfile, Intel VTune, and Callgrind. When we have JS scriptable profiling options available for all tier 1 platforms, we'll look at adding global start/stop profiling functions.

If you'd like to profile something at a higher level of detail than the JS Shark functions allow, there are corresponding C functions available at the bottom of jsdbgapi.h.

Costs Of Thread Safety

Currently, threadsafe SpiderMonkey costs us 10-15% on some benchmarks vs. a non-threadsafe JS shell. If you're looking to investigate that, build a standalone copy of SpiderMonkey and compare it with xpcshell.

Revision Source

<h3 id="Instructions" name="Instructions"> Instructions </h3>
<p>1.) Get yourself an optimized libxul build of Firefox, with debugger info.
</p><p>For the Mac, you'll want to read up on <a href="en/Profiling_JavaScript_with_Shark">Profiling JavaScript with Shark</a>. Here's a sample mozconfig:
</p>
<pre>mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-libxul
mk_add_options MOZ_MAKE_FLAGS=-j3
ac_add_options --enable-optimize
ac_add_options --enable-libxul
ac_add_options --enable-shark
ac_add_options --enable-debugger-info-modules
ac_add_options --enable-application=browser
</pre>
<p>2.) You'll want to run Shark on both the browser and [<a class="external" href="http://developer.mozilla.org/en/docs/XPCShell:Profiling">xpcshell</a>], since the host environments differ. Here are some instrumented tests to work from: <a fileid="322" href="File:en/Media_Gallery/Profiling-ammo.zip">media:Profiling-ammo.zip</a>
</p><p>3.) Once you have some changes you'd like try, you can just rebuild the js/src directory, since it produces its own shared library, even in libxul and static builds.
</p>
<pre>make -C my-obj-dir/js/src
</pre>
<h3 id="Other_Ways_To_Profile" name="Other_Ways_To_Profile"> Other Ways To Profile </h3>
<p>For Linux, there are global jprof functions available. See the documentation on the --enable-jprof mozconfig option. We're working to add support for other profilers, such as OProfile, Intel VTune, and Callgrind. When we have JS scriptable profiling options available for all tier 1 platforms, we'll look at adding global start/stop profiling functions.
</p><p>If you'd like to profile something at a higher level of detail than the JS Shark functions allow, there are corresponding C functions available at the bottom of <a class="external" href="http://mxr.mozilla.org/mozilla-central/source/js/src/jsdbgapi.h">jsdbgapi.h</a>.
</p>
<h3 id="Costs_Of_Thread_Safety" name="Costs_Of_Thread_Safety"> Costs Of Thread Safety </h3>
<p>Currently, threadsafe SpiderMonkey costs us 10-15% on some benchmarks vs. a non-threadsafe JS shell. If you're looking to investigate that, build a standalone copy of SpiderMonkey and compare it with xpcshell.
</p>
Revert to this revision