anp

Local checkout: cff07db629d

Here's the baseline stage1 size without instrumentation:

rust master *$ > $ llvm-size --format=sysv .\build\x86_64-pc-windows-msvc\stage1\bin\rustc_driver-6bca00ecd48151cb.dll     
.\build\x86_64-pc-windows-msvc\stage1\bin\rustc_driver-6bca00ecd48151cb.dll  :
section         size         addr
.text       93358380   6442455040
.rdata      31787826   6535815168

anp

"""
This is the product of me spending a few minutes trying to
assess how much of my LastPass vault is potentially vulnerable
to the recent CloudFlare issue.

It's hacky, and probably broken in some way, but it's a start.

Gist comments with improvements very welcome.
"""

anp

#!/usr/bin/env python2

# butchered from https://github.com/huonw/travis-cargo
# under MIT license

from __future__ import print_function
import argparse
import os
import sys
import subprocess

anp

Context

TLDR: I'm looking for any advice on how to improve the benchmarks below so I can have confidence in the results before moving on to the next feature in this project.

I'm currently working on a tool which relies heavily on the performance of Rust's HashMap implementation in the standard library. Since reading about the cryptographic hashing algorithm used in the standard library, I've been wondering if I couldn't improve the performance of my program just by swapping out the hashing algorithm (using the unstable hashmap_hasher feature).

The benchmarks mimic the program (which takes short 7-15 byte vectors and counts them and their positions in a source string), with the exception that instead of accumulating bytestring locations as well as counts, these benchmarks just count the instances. I hoped to do this to approximate the lookup and mutation costs of the HashMap without also mixing Vec's performance in the benchmark (because I can't affect that using different hashing algorithms).

There