Perform state-of-the-art benchmarks on a 64 bits platform. Test on a mono-core system + multi-core system, and compare. Test against different kinds of work-loads, performances against different sizes of DBs (large and very small), and compare.

Those results will be necessary to spot optimization points for #2

from sonic.

Some logs from our batch-import script; Sonic ~75% 1 CPU, this is per-1000 request:

Step: cursor #79000; took 0.251 sec (worst 0.475 sec; best 0.17 sec)
Step: cursor #80000; took 0.276 sec (worst 0.475 sec; best 0.17 sec)
Step: cursor #81000; took 0.273 sec (worst 0.475 sec; best 0.17 sec)
Step: cursor #82000; took 0.283 sec (worst 0.475 sec; best 0.17 sec)
Step: cursor #83000; took 0.239 sec (worst 0.475 sec; best 0.17 sec)
Step: cursor #84000; took 0.279 sec (worst 0.475 sec; best 0.17 sec)

from sonic.

Test the following operations at scale:

• PUSH
• POP
• SEARCH
• SUGGEST

Measure the 95th percentile, mean, median values and put all of this in a beautiful Markdown table in README.

from sonic.

Would be good to use a code tracing utility, to analyze which expression / function call / block does take the most time or is repeated too often.

from sonic.

Checklist:

• Add benchmarks to the tests; and provide clear cargo bench results (see: https://doc.rust-lang.org/1.2.0/book/benchmark-tests.html)
• Follow: http://www.codeofview.com/fix-rs/2017/01/24/how-to-optimize-rust-programs-on-linux/ for more advanced CPU tick tracing

from sonic.

All good!

from sonic.