Add benchmarks for KDirWatch
Summary:
All benchmarks create a relatively large directory tree and then
watch that recursively. On my system, the timings are:
RESULT : KDirWatch_UnitTest::benchCreateTree():
34.2 msecs per iteration (total: 342, iterations: 10)
PASS : KDirWatch_UnitTest::benchCreateWatcher()
RESULT : KDirWatch_UnitTest::benchCreateWatcher():
13.6 msecs per iteration (total: 137, iterations: 10)
PASS : KDirWatch_UnitTest::benchNotifyWatcher()
RESULT : KDirWatch_UnitTest::benchNotifyWatcher():
113.7 msecs per iteration (total: 1,138, iterations: 10)Note that this time includes wait/sleep time and the latency
induced by the kernel for the inotify events to arrive. Measuring
on-CPU time can be done by passing -perf to the benchmarks:
PASS : KDirWatch_UnitTest::benchCreateTree():
RESULT : KDirWatch_UnitTest::benchCreateTree():
165,910,830.4 CPU cycles per iteration (total: 1,659,108,304, iterations: 10)
PASS : KDirWatch_UnitTest::benchCreateWatcher()
RESULT : KDirWatch_UnitTest::benchCreateWatcher():
64,014,469.8 CPU cycles per iteration (total: 640,144,699, iterations: 10)
PASS : KDirWatch_UnitTest::benchNotifyWatcher()
RESULT : KDirWatch_UnitTest::benchNotifyWatcher():
316,077,005.5 CPU cycles per iteration (total: 3,160,770,055, iterations: 10)The first benchmark measures the time it takes to create the large
directory. See below for why this is useful information.
The second measures how long it takes to add the root dir
and its contents recursively.
The third one touches all files in the tree and measure how long it
takes until all dirty signals arrive. If you subtract the results
from the first benchmark from those of the third benchmark, you
arrive you arrive at the overhead imposed by KDirWatch.
At this point, it's quite high!
Reviewers: dfaure
Subscribers: Frameworks
Tags: Frameworks
Differential Revision: https://phabricator.kde.org/D9822