http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
Bug ID: 59177 Summary: steady_clock::now() and system_clock::now do not use the vdso (and are therefore very slow) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: luto at mit dot edu std::chrono::steady_clock::now() does this: #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL syscall(SYS_clock_gettime, CLOCK_MONOTONIC, &tp); #else clock_gettime(CLOCK_MONOTONIC, &tp); #endif I'm not sure what the intent of this condition is, but the effect is that glibc's clock_gettime (which is very carefully optimized and avoids using syscalls) is ignored in favor of using syscall(2) (which is very slow). This appears to have been introduced by this commit: http://gcc.gnu.org/ml/libstdc++/2013-05/txtfX2KusGj9C.txt It's a serious slowdown: steady_clock::now(): 0.0933114µs per iteration clock_gettime: 0.0230129µs per iteration as measured by: #include <chrono> #include <iostream> #include <time.h> using namespace std; constexpr int iters = 10000; typedef chrono::duration<double> dsecs; int main() { auto start = chrono::steady_clock::now(); for (int i = 0; i < iters; i++) chrono::steady_clock::now(); auto end = chrono::steady_clock::now(); std::cout << "steady_clock::now(): " << 1e6 * chrono::duration_cast<dsecs>(end-start).count() / iters << "µs per iteration\n"; start = chrono::steady_clock::now(); timespec ts; for (int i = 0; i < iters; i++) clock_gettime(CLOCK_MONOTONIC, &ts); end = chrono::steady_clock::now(); std::cout << "clock_gettime: " << 1e6 * chrono::duration_cast<dsecs>(end-start).count() / iters << "µs per iteration\n"; } system_clock appears to behave identically.