utility: add benchmark library, but don't use it yet. #2350
Conversation
to the other handlers with a browser. Add a private mechanism to have admin handlers supply arbitrary headers. Note that the handler callback doesn't expose a header structure, so the public v2 API does not provide this header-control. However, it was specifying text/html as content-type by default, so I changed the default to text/plain (with nosniff). Added sanitization of both the prefix string and the help text, which need to be safely injected into the HTML doc. Added some styling and a reference to the existing Envoy favicon as well. Note that no existing handlers get any response bytes changed as a result of this commit, just their content-type. Signed-off-by: Joshua Marantz <jmarantz@google.com>
…ms in particular. Signed-off-by: Joshua Marantz <jmarantz@google.com>
… can set the content-type and/or cache-control. Signed-off-by: Joshua Marantz <jmarantz@google.com>
This is extracted from envoyproxy#2348 and needs to go in first -- with no code depdning on it -- so the CI works in the PR which uses the new dependency. Signed-off-by: Joshua Marantz <jmarantz@google.com>
|
Note: I tried for several hours to get this to work with genrule_repository and raw genrule before giving up. There don't appear to be any currently live examples of this flow working with a non-trivial C++ dependency, although @htuch pointed out there was one in the past: Line 317 in 6f91542 But I had a hard time understanding how I would use this with an external github repo at a commit, as opposed to a versioned static file with a sha256. I'm OK revisiting this later but right now this is something that IMO we need to fix a real perf issue. |
|
@jmillikin-stripe can you provide an idea of what folks should be doing with |
I'm fine in general with using build recipes, but note that this particular recipe has some issues (e.g. it creates its own, non-hermetic googletest checkout). What are the chances that this official Google benchmark framework could grow a build config for use with Google's official build system...? |
|
The chance is pretty good we can get Bazel support: google/benchmark#501 However I don't want to wait for that :) I was able to get a good hint from one of the devs and managed to remove the gtest dependency. |
Signed-off-by: Joshua Marantz <jmarantz@google.com>
|
RE 'archive tarballs' -- how do they work? Is that something that has to be created by the repo owner? |
|
See https://developer.github.com/v3/repos/contents/#get-archive-link The link you'd want for google/benchmark is: https://github.com/google/benchmark/archive/e1c3a83b8197cf02e794f61228461c27d4e78cfb.tar.gz |
| @@ -0,0 +1,22 @@ | |||
| #!/bin/bash | |||
|
|
|||
| set -x | |||
There was a problem hiding this comment.
Remove -x (once done debug) and add -e.
| cd ../benchmark | ||
|
|
||
| pwd | ||
| include_dir="$THIRDPARTY_BUILD/include/testing/base/public" |
There was a problem hiding this comment.
Prefer INCLUDE_DIR for consistency with other variables (I know in Google we use lowercase, but we would need to switch everything over).
There was a problem hiding this comment.
done; FWIW I thought lower-case variables were common in bash, and upper-case variables when they are exported.
There was a problem hiding this comment.
They are, and it's in the Google style guide, but we haven't had that convention in Envoy, so we tend to opt to be consistent with the existing code base as the lesser evil.
| cp src/libbenchmark.a "$THIRDPARTY_BUILD"/lib | ||
| cd ../benchmark | ||
|
|
||
| pwd |
Signed-off-by: Joshua Marantz <jmarantz@google.com>
|
@jmarantz I think you may have skipped the push after update. |
|
What's the next step for this PR...I am not (yet) a collaborator so I can't merge myself. |
Adds a benchmarking for new string utility functions added in #2368 using the google microbenchmarking library (https://github.com/google/benchmark), which was added in #2350. This serves as an example and proof of concept on how to use the benchmarking library, and as a reference point for the approximate performance of some string-parsing functions. Risk Level: Very Low Testing: This is just a new speed-test, so running it on its own is sufficient to test it. Results: 2018-01-18 08:01:44 Run on (12 X 3800 MHz CPU s) CPU Caches: L1 Data 32K (x6) L1 Instruction 32K (x6) L2 Unified 256K (x6) L3 Unified 15360K (x1) ***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead. ------------------------------------------------------------------------------------- Benchmark Time CPU Iterations ------------------------------------------------------------------------------------- BM_RTrimStringView 11 ns 11 ns 54467092 BM_RTrimStringViewAlreadyTrimmed 9 ns 9 ns 77143046 BM_RTrimStringViewAlreadyTrimmedAndMakeString 24 ns 24 ns 29094696 BM_FindToken 165 ns 165 ns 4230849 BM_FindTokenValueNestedSplit 427 ns 427 ns 1653627 BM_FindTokenValueSearchForEqual 180 ns 180 ns 4046401 In practice I did not find this benchmark to be noisy on repeated runs. Signed-off-by: Joshua Marantz <jmarantz@google.com>
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
The Google Test repository has endorsed Abseil's "live at head" philosophy. Bump to a newer commit that includes google/googletest/envoyproxy#2350 for ease of writing tests. Signed-off-by: Alex Konradi <akonradi@google.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
Signed-off-by: Mike Schore <mike.schore@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
title: one line description
This is a prereq for running CI on #2348
Description:
Integrates github.com/google/benchmark so it can be used in future PRs for demonstrating improvement. Note this PR does not actually depend on it, so it can pass CI.
Risk Level: Low
Tested: //test/...