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:
Executes a fixed stress test - this gives us a performance measure for the machine running the test
Execute performance tests
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.
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:
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.