When run with two arguments (the two data files to be
compared), it will give a summary of each and a comparison between them. Here is
the comparison between the first benchmark (the control) and the second (with the
Listing#location cache improvement):
164 | Chapter 6: Performance
$ perf_comp a/perf_run.searches_create.txt b/perf_run.searches_create.txt
perf data file 1: a/perf_run.searches_create.txt
requests=100, options=-bm=searches_create
perf data file 2: b/perf_run.searches_create.txt
requests=100, options=-bm=searches_create
page c1 real c2 real c1 r/s c2 r/s c1 ms/r c2 ms/r c1/c2
searches_create 44.70490 43.13935 2.2 2.3 447.05 431.39 1.04
all requests 44.70490 43.13935 2.2 2.3 447.05 431.39 1.04
This is mostly information we have seen before. The interesting bit of information is
the far-right number in the table (1.04): the ratio of the old runtime to the new. In
this case, we see that the cache optimization afforded us a 4% improvement in overall
runtime on this action. This is a decent performance improvement, for an action
that is already fairly well optimized.
Compare that to the second optimization, the refactoring:
$ perf_comp b/perf_run.searches_create.txt c/perf_run.searches_create.txt
perf data file 1: b/perf_run.searches_create.txt
requests=100, options=-bm=searches_create
perf data file 2: c/perf_run.searches_create.txt
requests=100, options=-bm=searches_create
page c1 real c2 real c1 r/s c2 r/s c1 ms/r c2 ms/r c1/c2
searches_create 43.
Pages:
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255