add new page and remove

This change removes the old and out-of-date and
replaces it with documentation on our actual working performance
monitoring system.

Change-Id: I8aeb735bae5563cd4caf43523b0f6409b6a2d8e3
Reviewed-by: David Chase <>
diff --git a/ b/
deleted file mode 100644
index be066bf..0000000
--- a/
+++ /dev/null
@@ -1,68 +0,0 @@
-title: PerfDashboard
-*The perf dashboard is unmaintained and currently not active*
-## Introduction
-[Performance Dashboard]( does continuous monitoring of performance characteristics of the Go implementation. It notifies codereview threads about any significant changes caused by the commit, allows to see performance changes caused by [recent commits](, allows to investigate changes [in detail]( .
-## Builders
-The dashboard uses two builders: linux-amd64 running Ubuntu 14.04 and windows-amd64 running Windows 8.1. Both builders has the same hardware: 2 x Intel Xeon E5620 @ 2.4GHz, 8 HT cores, 12GB RAM.
-## Benchmarks
-The builders run benchmarks from the [x/benchmarks]( repo:
-  * ` json `: marshals and unmarshals large json object, in several goroutines independently.
-  * ` http `: http client and server serving "hello world", uses persistent connections and read/write timeouts.
-  * ` garbage `: parses net package using go/parser, in a loop in several goroutines; half of packages are instantly discarded, the other half is preserved indefinitely; this creates significant pressure on the garbage collector.
-  * ` build `: does 'go build -a std'.
-## Metrics
-Metrics collected are:
-  * ` allocated `: amount of memory allocated, per iteration, in bytes
-  * ` allocs `: number of memory allocations, per iteration
-  * ` cputime `: total CPU time (user+sys from time Unix utility output), can be larger than time when GOMAXPROCS>1, per iteration, in ns
-  * ` gc-pause-one `: duration of a single garbage collector pause, in ns
-  * ` gc-pause-total `: total duration of garbage collector pauses, per iteration, ns
-  * ` latency-50/95/99 `: request latency percentile, in ns
-  * ` rss `: max memory consumption as reported by OS, in bytes
-  * ` sys-gc `: memory consumed by garbage collector metadata (` MemStats.GCSys `), in bytes
-  * ` sys-heap `: memory consumed by heap (` MemStats.HeapSys `), in bytes
-  * ` sys-other `: unclassified memory consumption (` MemStats.OtherSys `), in bytes
-  * ` sys-stack `: memory consumed by stacks (` MemStats.StackSys `), in bytes
-  * ` sys-total `: total memory allocated from OS (` MemStats.Sys `), in bytes
-  * ` time `: real time (essentially the same as std Go benchmarks output), per iteration, in ns
-  * ` virtual-mem `: virtual memory consumption as reported by OS, in bytes
-And for build benchmark:
-  * ` binary-size `: size of the go command, in bytes
-  * ` build-cputime `: CPU time spent on the build, in ns
-  * ` build-rss `: max memory consumption of the build process as reported by OS, in bytes
-  * ` build-time `: real time of the build, in ns
-## Profiles
-The dashboard also collects a set of profiles for every commit, they are available from the [details page]( For usual benchmarks [CPU]( and [memory]( profiles are collected. For build benchmark - [perf profile](, [per-process split of CPU time]( and [per-section size](
-## Perf Changes View
-The [view]( allows to see aggregate information about significant performance changes caused by recent commits.
-  * The first row shows difference between the latest release and tip.
-  * The rest of the rows show deltas caused by individual commits.
-  * The first column is commit hash.
-  * Second - number of benchmarks that were executed for the commit to far.
-  * Third - metric name, or the special 'failure' metric for build/runtime crashes.
-  * Fourth - negative deltas.
-  * Fifth - positive deltas.
-  * The rest describe commit.
-You can click on any positive/negative delta to see details about the change.
diff --git a/ b/
new file mode 100644
index 0000000..442a34a
--- /dev/null
+++ b/
@@ -0,0 +1,111 @@
+title: PerformanceMonitoring
+The Go project monitors the performance characteristics of the Go implementation
+as well as that of subrepositories like
+## Benchmarks
+`` is the entrypoint for our performance tests.
+For Go implementations, this runs both the
+[Sweet]( (end-to-end benchmarks)
+and [bent]( (microbenchmarks)
+benchmarking suites.
+For the `` project, it runs the repository's benchmarks.
+These benchmarks can all be invoked manually, as can `cmd/bench`, but using both
+Sweet and bent directly will likely offer a better user experience.
+See their documentation for more details.
+## Performance testing principles
+### Change with the times
+Our set of benchmarks is curated.
+It is allowed to change over time.
+Sticking to a single benchmark set over a long period of time can easily land
+us in a situation where we're optimizing for the wrong thing.
+### Always perform a comparison
+We never report performance numbers in isolation, and only relative to some
+This strategy comes from the fact that comparing performance data taken far
+apart in time, even on the same hardware, can result in a lot of noise that
+goes unaccounted for.
+The state of a machine or VM on one day is likely to be very different than
+the state of a machine or VM on the next day.
+We refer to the tested version of source code as the "experiment" and the
+baseline version of source code as the "baseline."
+## Presubmit
+Do you have a Gerrit change that you want to run against our benchmarks?
+Select a builder containing the word `perf` in the "Choose Tryjobs" dialog that
+appears when selecting a [SlowBot](
+There are two kinds of presubmit builders for performance testing:
+- `perf_vs_parent`, which measures the performance delta of a change in isolation.
+- `perf_vs_tip`, which measures the performance delta versus the current
+  tip-of-tree for whichever repository the change is for.
+  (Remember to rebase your change(s) before using this one!)
+There's a third special presubmit builder for the tools repository as well which
+contains the string `perf_vs_gopls_0_11`.
+This measures the performance delta versus the `release-branch-gopls.0.11` branch
+of the tools repository.
+## Postsubmit
+The [performance dashboard]( provides
+continuous monitoring of benchmark performance for every commit that is made to
+the main Go repository and other subrepositories.
+The dashboard, more specifically, displays graphs showing the change in certain
+performance metrics (also called "units") over time for different benchmarks.
+Use the navigation interface at the top of the page to explore further.
+The [regressions page](
+displays all benchmarks in order of biggest regression to biggest improvement,
+followed by all benchmarks for which there is no statistically clear answer.
+On the graphs, red means regression, blue means improvement.
+### Baselines
+In post-submit, the baseline version for Go repository performance tests is
+automatically determined.
+For performance tests against changes on release branches, the baseline is always
+the latest release for that branch (for example, the latest minor release for
+Go 1.21 on `release-branch.go1.21`).
+For performance tests against tip-of-tree, the baseline is always the latest
+overall release of Go.
+This is indicated by the name of the builder that produces these benchmark
+esults, which contains the string `perf_vs_release`.
+What this means is that on every minor release of Go, the baseline shifts.
+These baseline shifts can be observed in the [per-metric view](#per-metric-view).
+Performance tests on subrepositories typically operate against some known
+long-term fixed baseline.
+For the tools repository, it's the tip of the `release-branch-gopls.0.11`
+### Per-metric view
+Click on any graph's performance metric name to view a more detailed timeline
+of the performance deltas for that metric.
+![Image displaying which link to click to reach the per-metric
+This view is particularly useful for identifying the culprit behind a regression
+and for pinpointing the source of an improvement.
+Sometimes, a performance change happens because a benchmark has changed or
+because the baseline version being used as changed.
+This view also displays information about the baseline versions and the version
+of `` that was used to produce the results to help identify
+when this happens.
diff --git a/images/performance-monitoring-per-metric-link.png b/images/performance-monitoring-per-metric-link.png
new file mode 100644
index 0000000..255c5b5
--- /dev/null
+++ b/images/performance-monitoring-per-metric-link.png
Binary files differ