The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9f15f2258d7cae8cd12cb4ef7143ad648a958333

commit 9f15f2258d7cae8cd12cb4ef7143ad648a958333
Author: gavinp <gavinp@chromium.org>
Date: Fri May 20 16:10:40 2016

SimpleCache: open with fewer seeks.

There's usually no reason to read the file header before reading the
stream 0 (headers) data when opening a simple cache entry. By not doing
so, seeks in the critical path of the loading headers are reduced, which
should speed up http caching performance.

To be careful, the headers are still checked when the first read of data
(if any) is performed. This delays detecting hash collisions in the
cache, because the header data is required to compare keys (instead of
just hashes).

To compensate for the later key comparison, a SHA256 of the key is
stored as an optional prefix to the end of file record. This is used to
validate the key is correct before returning headers to the client.

Because the key checking logic is now totally migrated back into the
SimpleSynchronousEntry, we can return to reporting on key matching in
the SyncOpenResult histograms.

R=juliatuttle@chromium.org,asvitkine@chromium.org,rdsmith@chromium.org
BUG=611732

Review-Url: https://codereview.chromium.org/1977863003
Cr-Commit-Position: refs/heads/master@{#395083}

[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/backend_unittest.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/entry_unittest.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_backend_impl.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_entry_format.h
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_entry_impl.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_entry_impl.h
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_synchronous_entry.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_synchronous_entry.h
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_test_util.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_test_util.h
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_util.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_util.h
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/net/disk_cache/simple/simple_util_unittest.cc
[modify] https://crrev.com/9f15f2258d7cae8cd12cb4ef7143ad648a958333/tools/metrics/histograms/histograms.xml

Requesting merge to m52.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3b7225481e277fb9cbaadc6aa37654a59e0457f8

commit 3b7225481e277fb9cbaadc6aa37654a59e0457f8
Author: Gavin Peters <gavinp@chromium.org>
Date: Mon May 23 14:59:41 2016

SimpleCache: open with fewer seeks.

There's usually no reason to read the file header before reading the
stream 0 (headers) data when opening a simple cache entry. By not doing
so, seeks in the critical path of the loading headers are reduced, which
should speed up http caching performance.

To be careful, the headers are still checked when the first read of data
(if any) is performed. This delays detecting hash collisions in the
cache, because the header data is required to compare keys (instead of
just hashes).

To compensate for the later key comparison, a SHA256 of the key is
stored as an optional prefix to the end of file record. This is used to
validate the key is correct before returning headers to the client.

Because the key checking logic is now totally migrated back into the
SimpleSynchronousEntry, we can return to reporting on key matching in
the SyncOpenResult histograms.

R=juliatuttle@chromium.org,asvitkine@chromium.org,rdsmith@chromium.org
BUG=611732

Review-Url: https://codereview.chromium.org/1977863003
Cr-Commit-Position: refs/heads/master@{#395083}
(cherry picked from commit 9f15f2258d7cae8cd12cb4ef7143ad648a958333)

Review URL: https://codereview.chromium.org/2004913002 .

Cr-Commit-Position: refs/branch-heads/2743@{#4}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/backend_unittest.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/entry_unittest.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_backend_impl.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_entry_format.h
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_entry_impl.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_entry_impl.h
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_synchronous_entry.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_synchronous_entry.h
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_test_util.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_test_util.h
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_util.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_util.h
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/net/disk_cache/simple/simple_util_unittest.cc
[modify] https://crrev.com/3b7225481e277fb9cbaadc6aa37654a59e0457f8/tools/metrics/histograms/histograms.xml

gavinp@
Could you please check issue 614909?