docs/performance/Benchmarking.md

   1 # Benchmarking
   2
   3 ## Debug Builds
   4
   5 Debug builds (\--enable-debug) and non-optimized builds
   6 (\--disable-optimize) are *much* slower. Any performance metrics
   7 gathered by such builds are largely unrelated to what would be found in
   8 a release browser.
   9
  10 ## Rust optimization level
  11
  12 Local optimized builds are [compiled with rust optimization level 1 by
  13 default](https://groups.google.com/forum/#!topic/mozilla.dev.platform/pN9O5EB_1q4),
  14 unlike Nightly builds, which use rust optimization level 2. This setting
  15 reduces build times significantly but comes with a serious hit to
  16 runtime performance for any rust code ([for example stylo and
  17 webrender](https://groups.google.com/d/msg/mozilla.dev.platform/pN9O5EB_1q4/ooXNuqMECAAJ)).
  18 Add the following to your
  19 [mozconfig](/setup/configuring_build_options.html#using-a-mozconfig-configuration-file)
  20 in order to build with level 2:
  21
  22 ```
  23 ac_add_options RUSTC_OPT_LEVEL=2
  24 ```
  25
  26 ## GC Poisoning
  27
  28 Many Firefox builds have a diagnostic tool that causes crashes to happen
  29 sooner and produce much more actionable information, but also slow down
  30 regular usage substantially. In particular, \"GC poisoning\" is used in
  31 all debug builds, and in optimized Nightly builds (but not opt Developer
  32 Edition or Beta builds). The poisoning can be disabled by setting the
  33 environment variable
  34
  35 ```
  36     JSGC_DISABLE_POISONING=1
  37 ```
  38
  39 before starting the browser.
  40
  41 ## Async Stacks
  42
  43 Async stacks no longer impact performance since **Firefox 78**, as
  44 {{bug(1601179)}} limits async stack capturing to when DevTools is
  45 opened.
  46
  47 Another option that is on by default in non-release builds is the
  48 preference javascript.options.asyncstack, which provides better
  49 debugging information to developers. Set it to false to match a release
  50 build. (This may be disabled for many situations in the future. See
  51 {{bug(1280819)}}.
  52
  53 ## Accelerated Graphics
  54
  55 Especially on Linux, accelerated graphics can sometimes lead to severe
  56 performance problems even if things look ok visually. Normally you would
  57 want to leave acceleration enabled while profiling, but on Linux you may
  58 wish to disable accelerated graphics (Preferences -\> Advanced -\>
  59 General -\> Use hardware acceleration when available).
  60
  61 ## Flash Plugin
  62
  63 If you are profiling real websites, you should disable the Adobe Flash
  64 plugin so you are testing Firefox code and not Flash jank problems. In
  65 about:addons \> Plugins, set Shockwave Flash to \"Never Activate\".
  66
  67 ## Timer Precision
  68
  69 Firefox reduces the precision of the Performance APIs and other clock
  70 and timer APIs accessible to Web Content. They are currently reduce to a
  71 multiple of 2ms; which is controlled by the privacy.reduceTimerPrecision
  72 about:config flag.
  73
  74 The exact value of the precision is controlled by the
  75 privacy.resistFingerprinting.reduceTimerPrecision.microseconds
  76 about:config flag.
  77
  78 ## Profiling tools
  79
  80 Currently the Gecko Profiler has limitations in the UI for inverted call
  81 stack top function analysis which is very useful for finding heavy
  82 functions that call into a whole bunch of code. Currently such functions
  83 may be easy to miss looking at a profile, so feel free to *also* use
  84 your favorite native profiler. It also lacks features such as
  85 instruction level profiling which can be helpful in low level profiling,
  86 or finding the hot loop inside a large function, etc. Some example tools
  87 include Instruments on OSX (part of XCode), [RotateRight
  88 Zoom](http://www.rotateright.com/) on Linux (uses perf underneath), and
  89 Intel VTune on Windows or Linux.