<p><i>The way to make a program faster is to never let it get slower.</i></p>
-<p>We have a zero-tolerance policy for performance regressions. If a patch lands that regresses performance according to our benchmarks,
+<p>We have a zero-tolerance policy for performance regressions.
+If a patch lands that regresses performance according to our benchmarks,
then the person responsible must either back the patch out of the tree or drop everything immediately and fix the regression.</p>
<p>Common excuses people give when they regress performance are, "But the new way is cleaner!" or "The new
-way is more correct." We don't care. No performance regressions are allowed, regardless of the reason. There is no justification
+way is more correct." We don't care. No performance regressions are allowed, regardless of the reason. There is no justification
for regressing performance. None.</p>
<p>We have a number of benchmarks that we use to measure performance.</p>
<ol>
-<li>The <a href="http://www.veritest.com/benchmarks/i-bench/default.asp">i-bench test suite</a> is the most well-known cross-browser benchmark.
-The HTML Load Speed and JavaScript tests are the most important sub-tests in the suite. No check-in can regress the benchmark scores for these
-tests.
+<li>The i-Bench test suite is the most well-known cross-browser benchmark.
+The HTML Load Speed and JavaScript tests are the most important sub-tests in the suite.
+No check-in can regress the benchmark scores for these tests.
+As of this writing, you can get the i-Bench test suite from
+<a href="http://www.lionbridge.com/lionbridge/en-US/services/outsourced-testing/benchmark-software.htm">this page</a> on the Lionbridge website.
+After accepting the license agreement you'll be able to download the suite from an FTP site at pcmag.com.</li>
<li>The <a href="http://www.24fun.com/downloadcenter/benchjs/benchjs.html">24Fun test</a> has become a popular site for people testing JavaScript
-and DHTML performance. The scores on this test must also not regress.
-<li>Our internal page load test suite (called the PLT for short) must also not regress.
+and DHTML performance. The scores on this test must also not regress.</li>
+<li>Our internal page load test suite (called the PLT for short) must also not regress.
The PLT contains pages that are representative of sites that are encountered in
-the real world. The harness itself is built into Safari and is accessible from the <i>Debug</i> menu. You can actually make Safari run the PLT
-on any set of test pages. Unfortunately the pages we use internally at Apple contain copyrighted material and therefore cannot be open source at this time.
-We hope that in the future sites will be willing to donate snapshots of their front pages so that an open source cross-browser test suite can be developed
-with content that is not as homogenous as the i-bench pages.</li>
+the real world. The harness itself is built into Safari and is accessible from the <i>Debug</i> menu.
+You can actually make Safari run the PLT on any set of test pages.
+Unfortunately, the pages we use internally at Apple contain copyrighted material and therefore cannot be open source at this time.
+We hope that in the future sites will be willing to donate snapshots of their front pages so that an open source cross-browser
+test suite can be developed with content that is not as homogenous as the i-Bench pages.</li>
</ol>
<h3>Get Involved!</h3>
<dl>
<dt>Test for Regressions</dt>
-<dd>If you have your own performance tests, run WebKit through them daily. Make sure that the performance of the sites you care about
-does not regress. Test the above benchmarks on your hardware to help double-check that there have not been any regressions. Remember, the best
+<dd>If you have your own performance tests, run WebKit through them daily. Make sure that the performance of the sites you care about
+does not regress. Test the above benchmarks on your hardware to help double-check that there have not been any regressions. Remember, the best
way to stay fast is to never let your code become slower.
<dt>Open Source Benchmark</dt>
-<dd>We have discussed with Mozilla and Opera the idea of an open-source cross-browser benchmark. The stumbling block to the construction of such
+<dd>We have discussed with Mozilla and Opera the idea of an open-source cross-browser benchmark. The stumbling block to the construction of such
a test suite is that we need to get buy-in from high profile sites like <a href="http://www.google.com">Google</a>, <a href="http://www.amazon.com">Amazon</a>
-or <a href="http://www.yahoo.com">Yahoo</a> to use snapshots of their front pages in the benchmark. The benefits of having your site in such a benchmark
+or <a href="http://www.yahoo.com">Yahoo</a> to use snapshots of their front pages in the benchmark. The benefits of having your site in such a benchmark
are obvious, since browser vendors will make your sites faster as they optimize for the content of the benchmark.
<p>If you work for one of these high profile sites we encourage you to <a href="../../contact.html">contact us</a> if you are interested in having your
to such a benchmark.</p>
<dt>Profile with Shark</dt>
-<dd>OS X now has an excellent profiling tool called Shark. If you find operations that are slow in WebKit, we encourage you to use Shark to isolate
-performance problems and file bugs with that information.
<a href="http://developer.apple.com/tools/shark_optimize.html">Here is a link</a> to get you
+<dd>OS X now has an excellent profiling tool called Shark. If you find operations that are slow in WebKit, we encourage you to use Shark to isolate
+performance problems and file bugs with that information. <a href="http://developer.apple.com/tools/shark_optimize.html">Here is a link</a> to get you
started using Shark.
</dl>
git://git.webkit.org / WebKit-https.git / commitdiff