New issue
Advanced search Search tips

Issue 706878 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Speed up eviction candidate computation

Project Member Reported by morlovich@chromium.org, Mar 30 2017

Issue description

Whenever SimpleCache is computing candidates for eviction, no other cache ops can proceed on that cache, so it's important that it finish as quickly as possible.

(Metric: Eviction.TimeToSelectEntries)


 

Comment 1 by pasko@chromium.org, Mar 30 2017

even more, whenever simplecache is computing candidates for eviction, no other task can proceed on the IO thread :)

The optimization in your patch looks reasonable, the new code reads generally better. I'll take a closer look tomorrow.
Thanks. So is cache_thread_ == the main I/O thread? I probably ought to know that.
Oh, I think I've misread, cache_thread_ is just I/O for index read/write, isn't it, with all the book keeping on the I/O thread? 
Project Member

Comment 4 by bugdroid1@chromium.org, Apr 4 2017

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

commit c348edb0c510441efe4ae5b8b1cfccc47f3c15ce
Author: morlovich <morlovich@chromium.org>
Date: Tue Apr 04 20:23:23 2017

Speed up SimpleCache eviction set computation

The code previously used to collect hash keys into vector and
sort that by LRU order, which required indexing into the hash
table on every comparison.

Instead, collect pointers into the hashtable (which are same size), to
avoid the hash lookups.

CPU impact: new SimpleIndexPerfTest, EvictionPerformance ubenchmark:
4.82ms -> 0.33ms on Linux/clang workstation
9.26ms -> 0.64ms on Windows/MSVC laptop
(With 10K entries)

Memory usage impact:
Let N = number of entries in cache. E = number of entries evicted,
which is usually around N/20.

My workstation currently has 16325 entries in cache, which is within the "not-surprising" range, so I'll plug N=16000 plus corresponding E=800 into formulas to eyeball numbers.

32-bit:
Peak/short-term usage (not counting any vector rounding) goes from:
8*N -> 4*N + 8*E
e.g. 128,000 -> 70,400

Long-term, while I/O going on, usage goes from:
8*N -> 8*E
e.g. 128,000 -> 6,400

64-bit:
Shurt-term
8*N -> 8*N + 8*E
e.g. 128,000 -> 134,400

Long-term, while I/O going on, usage goes from:
8*N -> 8*E
e.g. 128,000 -> 6,400

BUG= 706878 

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

[modify] https://crrev.com/c348edb0c510441efe4ae5b8b1cfccc47f3c15ce/net/disk_cache/disk_cache_perftest.cc
[modify] https://crrev.com/c348edb0c510441efe4ae5b8b1cfccc47f3c15ce/net/disk_cache/simple/simple_index.cc
[modify] https://crrev.com/c348edb0c510441efe4ae5b8b1cfccc47f3c15ce/net/disk_cache/simple/simple_index.h

Looks good thus far, but want to confirm it on Beta before closing.
Status: Fixed (was: Started)

Sign in to add a comment