You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
jianglk.darker 7ee447c011
v811_spc009_project
4 months ago
..
Android.bp v811_spc009_project 4 months ago
README.md v811_spc009_project 4 months ago
bpf_benchmark.cpp v811_spc009_project 4 months ago
connect_benchmark.cpp v811_spc009_project 4 months ago
dns_benchmark.cpp v811_spc009_project 4 months ago
main.cpp v811_spc009_project 4 months ago

README.md

NetD benchmarks

These are benchmarks for libc connect and gethostbyname functions as hooked by netd.

Infrastructure

The benchmarks are powered by google-benchmark, which records four statistics:

Statistic Meaning
real_time Mean wall-clock time taken for each iteration of the function under test to complete. This includes any time spent in other processes.

Some of the **connect** benchmarks override this by implementing their own timings, but the semantics are roughly the same. See connect_benchmark.cpp for details.

cpu_time Mean time spent in the current thread during each iteration of the function under test. This does not include any time spent in other processes or blocking on I/O.

Since almost all of the functionality we are testing here is in the netd server, not the client, these timings are not relevant and should be ignored for most purposes.

iterations The number of runs of the test function that were executed, across all threads, in order for the test to reach the minimum amount of time run. Most tests here define 'minimum time run' in terms of real time or 'manual time', rather than CPU time, for the reasons above.

This should be roughly inversely proportional to **real_time** for single-threaded benchmarks and also somewhat proportional to the number of threads used.

label Field that the benchmark can fill with an arbitrary string.

For graphing purposes, a few of the benchmarks in this directory store the 90th-percentile latency in this field for comparison against the mean latency (it's only possible to plot one other value apart from mean).

If the graphing ecosystem ever becomes advanced enough to plot multiple outputs from one label, it might be more useful to log every decile to get a better picture of how spiky things are.

Methods currently being benchmarked

connect()

getaddrinfo()