The application uses Mercurial,
a distributed version-control system, which makes it very easy to test large,
complicated changes and then pull all, some, or no changes back into the main codebase,
depending on their performance improvement. In this case, we used source control
to run benchmarks on several different optimizations after the fact, to see how
much of an improvement each one made.
We followed the following (simplified) process with Mercurial:
1. Clone the main trunk repository to a new repository and copy over any necessary
nonversioned configuration files (such as config/database.yml).
$ hg clone trunk performance-testing
$ cp trunk/config/database.yml performance-testing/config/
2. In the new repository, repeat the profile-optimize-test cycle and check in each
change.
$ cd performance-testing
(make changes, test)
$ hg ci
3. If the performance improvements were successful, pull the changes back into the
main repository.a
$ cd ../trunk
$ hg pull -u ../performance-testing
$ hg up
We examine the distributed version-control paradigm in more detail in Chapter 10.
a The Mercurial Queues extension (also called MQ; its use is detailed at http://www.selenic.com/mercurial/
wiki/index.cgi/MqExtension) makes this process much more straightforward, and makes it easier to cherrypick
or throw away individual changes (even while working in the main repository).
Pages:
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251