Database Reference
In-Depth Information
{:added ""1.2""}
[^CharSequence s]
(.. s toString trim))
nil
We can see that the parameter to the
string/trim
function is a
CharSequence
, and the
compiler can use this information to know which
toString
to dispatch to.
See also
F
For more information on the pros and cons of different methods of benchmarking
and what the Criterium library does, see the
Benchmarking with Criterium
recipe
F
For more information on Monte Carlo methods, see the
Partitioning Monte Carlo
simulations for Better pmap Performance
recipe
Benchmarking with Criterium
Benchmarking can be an important part of the data analysis process. Especially when faced
with very large datasets that need to be processed in multiple ways, choosing algorithms that
will inish in a reasonable amount of time is important. Benchmarking gives us an empirical
basis on which to make these decisions.
For some of the recipes in this chapter, we've used the Criterium library (
https://github.
com/hugoduncan/criterium
). Why will we want to go to the trouble of using an entire
library just to see how fast our code is?
Generally, when we want to benchmark our code, we often start by using something similar
to the
time
macro. This means:
1.
Get the start time.
2.
Execute the code.
3.
Get the end time.
If you've done this often, you will realize that this has a number of problems, especially for
benchmarking small functions that execute quickly. The times are often inconsistent, and
they can be dependent on a number of factors that are external to your program, such as
the memory or disk cache. Using this benchmarking method often ends up being an
exercise in frustration.
Fortunately, Criterium takes care of all of this. It makes sure that the caches are warmed
up, runs your code multiple times, and presents a statistical look at the execution times.
This presents more information than just a single raw time. It also presents a lot of other
useful information, such as how much time is spent in garbage collection.
