The benchmarks in tests/test-benchmark.lua have two modes. When CI=1 is set in
the environment, only a "quick" and less exact test is done. Otherwise, a slower
and more exact measurements is taken. This was added so that we do not waste CPU
time on travis.
However, most of the time the user running "make check" doesn't want exact
measurements either. So instead of only being quick when CI=1 is set, this
commit changes the logic to always being quick unless BENCHMARK_EXACT=1 is set.
Additionally, a message is printed next to the benchmark results so that the
user is reminded to set this var if the measurements should actually mean
something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently some of the last commits speeds up create_wibox() a lot. This
highlights that this is a bad test: After creating thousands of wiboxes, awesome
needed 15 seconds to draw all of them and in the end some dbus timeout aborted
the test run.
However, it's irrelevant how quickly we can create wibox. The interesting number
is how quickly we can display a new wibox. Thus, this commits changes the code
so that it also measures the time that is needed to update the wibox. This way,
we don't accumulate a huge number of pending repaints and everything's fine.
Some results (but there is nothing to compare this with):
create&draw wibox: 0.0373947 sec/iter ( 28 iters, 1.59 sec for benchmark)
update textclock: 0.00198174 sec/iter (515 iters, 1.937 sec for benchmark)
relayout textclock: 0.000614439 sec/iter (1710 iters, 1.051 sec for benchmark)
redraw textclock: 0.00116882 sec/iter (865 iters, 2.962 sec for benchmark)
tag switch: 0.000705579 sec/iter (1498 iters, 3.703 sec for benchmark)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This (ab)uses the integration tests to run a benchmark. This currently only
measures wibox drawing performance. To avoid wasting CPU-cycles, this does only
a quick run under travis while on "normal" runs the function under test is
executed in a loop to improve the precision of the measurement.
This benchmarks hopefully allow to optimize things in a clear fashion instead of
things like "it feels faster to me".
Results when run against the previous commit:
== Running test-benchmark.lua ==
create wibox: 0.0788958 sec/iter ( 13 iters, 1.103 sec for benchmark)
update textclock: 0.019493 sec/iter ( 56 iters, 2.507 sec for benchmark)
relayout textclock: 0.0160725 sec/iter ( 63 iters, 1.029 sec for benchmark)
redraw textclock: 0.0015601 sec/iter (647 iters, 1.875 sec for benchmark)
W: awesome: a_glib_poll:291: Last main loop iteration took 6.593912 seconds! Increasing limit for this warning to that value.
Results right before the new widget layouts were merged (commit 52154d0f15):
== Running test-benchmark.lua ==
create wibox: 0.0782874 sec/iter ( 13 iters, 1.095 sec for benchmark)
update textclock: 0.00736755 sec/iter (136 iters, 1.346 sec for benchmark)
W: awesome: luaA_dofunction:77: error while running function
[...]
error: /home/psychon/projects/awesome/build/lib/gears/object.lua:30: Trying to emit non-existent signal 'widget::layout_changed'
Closes https://github.com/awesomeWM/awesome/pull/451.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
actionless