Guardrails can now have a much smaller impact on your dev-time performance!
I realized that most of the time in dev mode you’re just running bits of code here and there in fits and starts.
Most people rarely run super high numbers of iterations without some kind of pause. Even then: if you’re running
such a computation there is still a high probability that you’ll see problems even if some of the checks are silently
As a result, guardrails now has an asynchronous checking mode (which mainly benefits Clojure)!
When this mode is enabled it pushes spec checking into a
core.async channel with a dropping buffer (size 10,000). The overhead
put is just a few microseconds. This allows an alternate thread to run the checks, and as long as you
don’t have large sustained computations this can give you nearly full-production performance of your code, while
an alternate core in your computer handles the checks.
Much faster dev performance (Clojure only. The option works in CLJS, but there’s not a second thread so there is
High performance algorithms can use guardrails with a tolerable cost.
Checking results are queued. If a lot of slow checks get in the queue you might have to wait some time before
you see the problems. This could cause confusion (you might be running your next expression in the REPL and see an error from the
Not all checks will run in a CPU-intensive task that queues checks rapidly.
Async mode is incompatible with the
:throw? true option.
To enable the async mode, just add
:async? true in your