title: Benchmarking with googletest?
body: <h2>Background (skip to Question below if not interested)</h2>
  <p>I have a simulator that runs through three states:</p>
  <ol>
  <li>Single threaded startup (I/O ok)</li>
  <li>Multi-threaded in-memory CPU-bound simulation stage <strong>(I/O not ok)</strong></li>
  <li>Post-simulation, post-join single threaded stage (I/O ok)</li>
  </ol>
  <p><strong>What the heck!</strong>  During standard testing, CPU usage dropped from <strong>100% down to 20%</strong>, and the total run took about <strong>30 times longer than normal (130secs vs 4.2secs).</strong></p>
  <p>When <code>Callgrind</code> revealed nothing suspicious, my head buzzed as I was on the precipice of rolling back to the last commit, losing all bug-fixes.</p>
  <p>Discouraged, I walked into the server room during a run and noticed nasty grinding sounds, verified later to be caused by writes to Mysql sockets in <a href="https://stackoverflow.com/questions/8181662/disk-io-profiler-for-a-c-application-on-linux">/proc/PID/fd</a>!!!  It turned out that Mysql code, several layers deep in Stage 2., was causing problems.</p>
  <p><strong>Lessons Learned</strong></p>
  <ol>
  <li>Accidental I/O can be lethal to a real-time application</li>
  <li>Unit testing is not enough:  I need benchmarking, too</li>
  </ol>
  <p><strong>Fix</strong>  I will introduce thread-local-storage IOSentinels and asserts() on ReadAllowed() and WriteAllowed() to ensure that Stage 2 threads will never do any IO.</p>
  <h2>Question</h2>
  <p><strong>Anyone have any luck with attaching/writing a benchmarking framework with googletest?</strong></p>
  <p>Unfortunately, all my googletests passed this time.  Had I stepped away for a bit and come back without noticing the run-time, this would have been a disastrous commit, and possibly much harder to fix.</p>
  <p>I would like googletest to fail if a run takes &gt;2 or 3 times the last runtime: this last part is tricky because for very quick runs, system state can cause something to take twice as long but still be ok.  But for a long simulation run/test, I don't expect runtimes to change by a great deal (&gt;50% would be unusual).</p>
  <p>I am open to suggestions here, but it would be nice to have a low-maintenance check that would work with automated testing so it will be obvious if the system suddenly got slow, even if all the outputs appear to be ok.</p>