Adds include of <termios.h> if system has it, in order to fix:
../perf/cairo-perf-print.c: In function ‘report_print’:
../perf/cairo-perf-print.c:62:28: error: storage size of ‘ws’ isn’t known
62 | struct winsize ws;
| ^~
../perf/cairo-perf-print.c:64:26: error: ‘TIOCGWINSZ’ undeclared
(first use in this function)
64 | if(ioctl(fd, TIOCGWINSZ, &ws) == 0 ) {
| ^~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
We *always* generate this file, and we depend on its existence.
The idea behind HAVE_CONFIG_H was being able to include random files
from different projects, back in a time where "libraries" were literally
just random files instead of actual shared objects.
Since we're not in the '80s any more, and our build system(s) define
HAVE_CONFIG_H *and* generate the config.h header file, we don't need a
conditional guard around its inclusion.
If running ./cairo-perf-print in a terminal, query the terminal size and
rescale the histogram to use the maximum available space.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If you call ./cairo-perf-print --histogram results.txt, it will then
print a histogram of the results, one per test. Ideally, you should see
a skewed distribution (with a negative skew representing that most results
run in optimal time), but random sampling errors (scheduling,
throttling, general inefficiency etc) will push it more towards a normal
distribution.
For example,
| x |
| x xx |
| x xx |
| x xx |
| xxxx |
| xxxx x |
| x xxxxxx |
| x xxxxxx |
| xxxxxxxxx |
| xxxxxxxxx |
| xxxxxxxxx |
| xxxxxxxxxxxx |
| xxxxxxxxxxxx |
| xxxxxxxxxxxx |
| xxxxxxxxxxxxxx |
|x xxxxxxxxxxxxxx |
|x x xxxxxxxxxxxxxxx |
|x x xxxxxxxxxxxxxxx |
|x x xxxxxxxxxxxxxxxxx |
|xxx x xxxxxxxxxxxxxxxxxxx |
|xxx xxxxxxxxxxxxxxxxxxxxxxxxx |
|xxxxxx xxxx x x x x xxx xx xxxxx xxx x xxx x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
.------------------------------------------------------------------------------.
xlib firefox-fishtank 8298.44 1.53% (829/946)
Starts off reasonably, but quickly deteriorates as the integrated CPU/GPU
overheats and is forced to throttle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After a run, it can be useful to reprint the results, so add
cairo-perf-print to perform that task.
For the future, I'd like to move the performance suite over to the
git/perf style of single, multi-function binary.
The sequence of operations that I typically do are:
./cairo-perf-trace -r -v -i 6 > `git describe`.`hostname`.perf
./cairo-perf-diff-files REVA REVB
./cairo-perf-print REVA
./cairo-perf-compare-backends REVA
which misses the caching available with cairo-perf-diff. 'make html' is
almost what I want, but still too prescriptive. However, that does need to
be addressed for continuous performance monitoring.
Along the perf lines, those sequence of operations become:
./cairo-perf record -i 6
./cairo-perf report
./cairo-perf report REVA REVB
./cairo-perf report --backends="image,xlib,gl" REVA REVB
./cairo-perf report --html REVA REVB
Also we want to think about installing the cairo-perf binary. So we want
to differentiate when run inside a git checkout.
