Add ^:const metadata for efficiency

[aengelberg]

For a speed comparison I tried this in the REPL:

(def ^:const seventy-one
  "The number seventy-one, i.e. 71."
  71)

(def seventy-one-not-const 71)

com.gfredericks.seventy-one> (time (dotimes [i 1e8] (* i seventy-one-not-const)))
"Elapsed time: 1823.769064 msecs"
nil
com.gfredericks.seventy-one> (time (dotimes [i 1e8] (* i seventy-one)))
"Elapsed time: 190.361232 msecs"
nil

You might want to try benchmarking with criterium to be absolute sure of the speed difference, but it's pretty obvious this is an essential performance boost for those looking to use this in production.

[suzaku]

:+1:

[gfredericks]

The tradeoff here is that we lose dynamic-runtime features, in particular we can't mock the behavior of seventy-one in tests using with-redefs, which I expect is pretty useful.

I'll have to give this one some thought.

[danielcompton]

Can you make sure these are laptop benchmarks?

[tcrayford]

Did you run those benchmarks with lein's default jvm optimizations? Lein turns off most of the standard jvm optimizations, which can severely inhibit inlining through vars. See https://github.com/dakrone/cheshire/pull/75 for another example.

[gfredericks]

What would folks think about having a separate var for this so people could opt-in to the restricted functionality if they wanted to? Maybe call it fast-seventy-one?

[dcmoore]

@gfredericks, I would love to see that feature.

[marcomorain]

In Spec-ulation, Rich suggests that adding a number to the end of names is a neat way to version things. How about the new var is named this this way?

seventy-one-two?

[gfredericks]

Or just seventy-one-const

[aengelberg]

Closing this since we don't seem to be approaching a resolution on making these changes ready to merge, but feel free to re-open if someone else wants to take it over the line.