GitLab

Add a simple HashedExtensionId class as a wrapper around a hex-encoded
SHA1 hash of an extension id, and store this in the Manifest class (with
the regular extension id). This allows us to compute the hash of an
extension id once, rather than recomputing it each time we calculate
feature availability.

Previously, we would calculate this hash each time we'd examine a
feature for availability - which happens during extension initialization
and loading, bindings set up, function execution and more. (This was
even worse because we would check the blacklist even if the list was
empty, resulting in calculating the hash for that case no matter what).

Fun Stats (local sampling, so your mileage may vary):
Before, opening Chromium with default extensions resulted in ~350 calls
to crx_file::id_util::HashedIdInHex() in both the browser process *and*
each renderer process (so a minimum of ~700 calls to just open chrome,
with additional tabs triggering an additional ~350 calls).

Now, opening Chromium with default extensions results in <10 calls to
crx_file::id_util::HashedIdInHex() in each process.

With an average run speed (on a debug build [slow] of a Z840 [fast] -
so maybe representative-ish of real situations?) of 0.034ms in the
browser process and 0.303ms in the renderer process, this corresponds
to a 11.9ms speed up in browser startup and 106ms speed up in renderer
startup. Note that each extension adds to this linearly, so if the user
had an extension with content scripts running on each page, this would
save ~700 renderer calls, resulting in a 212ms speed up.

Yay!

Bug: 622035
Bug: 755441

Change-Id: Idd5655982ad03ab55882d7b44a177a41fe1cb02c
Reviewed-on: https://chromium-review.googlesource.com/619663
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495984}