We're not tracking performance of the various OSRM pipeline tools right now. If we introduce a change that creates some large slowdown, we have no easy way to notice.

We should create a new Travis build configuration that does:

1. Executes a fixed stress test - this gives us a performance measure for the machine running the test
2. Execute performance tests
3. Report results relative to the fixed stress test

Over time, this will allow us to track how the code performs relative to the fixed stress test, and similar to code coverage, we could warn/fail the build if performance regresses. If we knowingly introduce a feature that slows things down, we can adjust the trigger threshold, but this process makes that explicit, rather than invisible.