Example performance document

Welcome to the preamble! Each performance document contains a section just below the table of contents that may be used to give introductory text to the sections that follow. We write in hiccup/html, so we can include elements like code examples.

(+ 1 2) ;; => 3

To include multiple html elements, we simply wrap them all in a hiccup [:div ...]. The text you are reading is sourced from the options file, associated to the :preamble key.

This performance document reports the results from running the benchmarks defines in these two namespaces. Don't take the data too seriously; the benchmarks are merely demonstrations.

In addition to the preamble, we may add text comments to each group, in this case, the group called 'custom `conj`', which Fastester uses for the section heading. Group comments are sourced from the :comments key of the options.

This group happens to involve only a single benchmark, but later groups will contain more than one. The version 5 conj function was implemented as usual, while the version 6 implementation uses transients for improved performance.

Interestingly, the transient conjoin implementation is always slower, for vectors spanning one to ten million elements. This represents a performance regression. We should consider leaving the original implementation as-is, and make an entirely new function for situations where the transient implementation is actually faster.

One final note: Fastester displays error bars indicating the standard deviation of the sampled measurements. This gives a sense of how tightly the data clusters. When the the error bars go negative and the y-axis is logarithmic, Fastester suppresses that particular error bar because it can not be displayed. A note highlights this occurrence below the chart, and the datum in the details table is called out.

Linear y-axes always display all error bars.

(fn [n] (my-conj (seq-of-n-rand-ints n) :tail-value))

This benchmark group demonstrates that the relative comparisons do not necessarily have be be sequential. In this case, we skipped version 5. Note the logarithmic scales on both the x- and y-axes. Also note the doall to force realization of the sequence.

This benchmark group does not involve any actual implementation change, so we don't see any significant performance difference between versions 4 and 6.

Another thing to note is that this group contains two benchmarks, the first incrementing numbers, the second upper-casing strings. It's intended to demonstrate map's performance spanning six orders of magnitude, with mapping functions handling two different data types.

(fn [n] (doall (map inc (range-of-length-n n))))

(fn [n] (doall (map str/upper-case (abc-cycle-of-length-n n))))

The three benchmarks in this group simulate performance enhancements to the addition function. To simulate this, delayed-+ is merely that: clojure.core/+ with an intentional delay that decreases from 60 milliseconds in version 3 to 10 milliseconds in version 6.

The group contains benchmarks measuring the addition of one, two, and three operands. For each of those three cases, we measure the evaluation times of integers of different sizes.

We don't expect addition to be dependent on the size of the operands, and in fact that's what we see, particularly since the intentional delay utterly swamps any other factor that might cause a measurable difference.

(fn [n] (delayed-+ n n n))

(fn [n] (delayed-+ n n))

(fn [n] (delayed-+ n))

Because the sequences grow from one element to one-hundred thousand elements long, the evaluation times of this group's single benchmark increase. We didn't change the implementation from versions 4 through 6 for this demonstration, so all three curves are stacked atop one another.

(fn [n] (apply + (seq-of-n-repeats n)))