NOTE: Text and overall strategy pulled completely from WebKit

Overview

Performance is a top priority for SproutCore. We adhere to a simple directive for all work we do on SproutCore.

The way to make a program faster is to never let it get slower.

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.

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 for regressing performance. None.

We have a number of benchmarks that we use to measure performance.

1. Description forthcoming.

Get Involved!

How can you help improve SproutCore’s performance?

Test for Regressions

If you have your own performance tests, run SproutCore 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.

Comments

We need a good performance benchmark testing system. Maybe someone could build a variant of the TestRunner?