
This CL has two parts: Part 1: This CL adds an experiment to base called IsRunningCpuReductionExperiment. When enabled, several different unrelated features will change their behavior to reduce overall CPU consumption of chrome. As these features are unrelated, this experiment must live in base as the only common dependency. Part 2: This CL modifies 6 functions that emit UMA metrics to emit at 1/1000th of their current rate. Combined, the UMA metric emission from these 6 functions are responsible for 0.33% of all CPU cycles on ChromeOS, including time from non-chrome processes. This demonstrates why the code in part 1 must live in base. Future CLs will add more CPU-savings to the experiment before it is enabled. Bug: 1295441 Change-Id: I8202c5a1482ff66fc90a7bc64bb36b3cdc773130 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3449251 Reviewed-by: Ken Rockot <rockot@google.com> Reviewed-by: Sunny Sachanandani <sunnyps@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Francois Pierre Doray <fdoray@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Commit-Queue: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/main@{#969512}
Chrome's URL library
Layers
There are several conceptual layers in this directory. Going from the lowest level up, they are:
Parsing
The url_parse.*
files are the parser. This code does no string
transformations. Its only job is to take an input string and split out the
components of the URL as best as it can deduce them, for a given type of URL.
Parsing can never fail, it will take its best guess. This layer does not
have logic for determining the type of URL parsing to apply, that needs to
be applied at a higher layer (the "util" layer below).
Because the parser code is derived (very distantly) from some code in
Mozilla, some of the parser files are in url/third_party/mozilla/
.
The main header to include for calling the parser is
url/third_party/mozilla/url_parse.h
.
Canonicalization
The url_canon*
files are the canonicalizer. This code will transform specific
URL components or specific types of URLs into a standard form. For some
dangerous or invalid data, the canonicalizer will report that a URL is invalid,
although it will always try its best to produce output (so the calling code
can, for example, show the user an error that the URL is invalid). The
canonicalizer attempts to provide as consistent a representation as possible
without changing the meaning of a URL.
The canonicalizer layer is designed to be independent of the string type of
the embedder, so all string output is done through a CanonOutput
wrapper
object. An implementation for std::string
output is provided in
url_canon_stdstring.h
.
The main header to include for calling the canonicalizer is
url/url_canon.h
.
Utility
The url_util*
files provide a higher-level wrapper around the parser and
canonicalizer. While it can be called directly, it is designed to be the
foundation for writing URL wrapper objects (The GURL later and Blink's KURL
object use the Utility layer to implement the low-level logic).
The Utility code makes decisions about URL types and calls the correct parsing and canonicalzation functions for those types. It provides an interface to register application-specific schemes that have specific requirements. Sharing this loigic between KURL and GURL is important so that URLs are handled consistently across the application.
The main header to include is url/url_util.h
.
Google URL (GURL) and Origin
At the highest layer, a C++ object for representing URLs is provided. This
object uses STL. Most uses need only this layer. Include url/gurl.h
.
Also at this layer is also the Origin object which exists to make security
decisions on the web. Include url/origin.h
.
Historical background
This code was originally a separate library that was designed to be embedded into both Chrome (which uses STL) and WebKit (which didn't use any STL at the time). As a result, the parsing, canonicalization, and utility code could not use STL, or any other common code in Chromium like base.
When WebKit was forked into the Chromium repo and renamed Blink, this restriction has been relaxed somewhat. Blink still provides its own URL object using its own string type, so the insulation that the Utility layer provides is still useful. But some STL strings and calls to base functions have gradually been added in places where doing so is possible.