summaryrefslogtreecommitdiff
path: root/test/benchmarks/src/main
Commit message (Collapse)AuthorAgeFilesLines
* SI-9789 use quadratic probing in OpenHashMapPerformant Data LLC2016-05-264-82/+251
| | | | | | | | | | | | The original probe sequence, taken from Python's hash table code, is exponential, jumping around in the hash table with poor memory locality. This replaces the probe algorithm with the more conventional quadratic probing. This also adds tests to the benchmarking code using AnyRef keys, which have pseudorandom hash codes (unlike Ints, whose hash code is simply the Int itself). The intensity of the benchmarking is reduced to make the tests complete within 9 hours, by removing unnecessary sampling.
* Address JMH benchmark reviewer's issues.Performant Data LLC2016-05-032-45/+39
| | | | | Besides tweaks to the documentation, this tests smaller (25-element) maps, and rewrites OpenHashMapRunner in more idiomatic Scala.
* Improve the OpenHashMapBenchmark run times.Performant Data LLC2016-05-031-7/+14
| | | | | For the warm-up invocations, suppress setup and teardown that is only needed for the measurement iterations. Reduce the number of forks.
* Add a JMH runner class to the library benchmark framework.Performant Data LLC2016-05-032-0/+127
|
* Benchmark the OpenHashMap memory usage.Performant Data LLC2016-05-031-10/+22
| | | | Also add sbteclipse to the benchmark project.
* Add get() tests to OpenHashMap, reduce timing artifacts.Performant Data LLC2016-05-031-35/+144
| | | | | | | | | | | | | | | | | | | | | In order to get a better exploration of the variance of tests in a limited time, I've reduced the number of measurement iterations and increased the number of forks. By sight, the measurement iterations seemed pretty consistent within a trial, whereas they would vary widely on occasional forks. I extended testing down to 50-entry maps, to explore the rise in service times that I was seeing at small scale. This is probably a timing artifact, from too-short invocations, since I'm using @Level.Invocation in the put() tests. To fix that, I enlarged the unit of testing, by creating multiple, sometimes thousands, of maps for the invocation to fill. This has also changed the test from filling a previously-filled map, to filling a new, but sufficiently sized map. The put()/remove() test now performs much worse (on a more realistic scenario). This also adds a couple tests for calling get() against a map that's been filled only with put()s, or with a mix of put() and remove().
* Add JMH to the benchmark framework.Performant Data LLC2016-05-031-0/+76
Add an example benchmark for OpenHashMap.