• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

ben-manes / caffeine / 1553
100%

Build:
DEFAULT BRANCH: master
Ran 07 Jan 2016 12:05PM UTC
Jobs 1
Files 63
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

pending completion
1553

push

travis-ci

ben-manes
Add fastpath for when the cache is under 50% capacity

When a cache is below the 50% threshold there is little advantage of
maintaining the size based eviction order. In this case the frequency
sketch is already being lazily initialized to reduce the footprint. The
read buffers (recording, draining) can also be skipped. This avoids
maintenance cycles to perform the LRU reordering. The assumption is
that realistic workloads (long traces) of full caches will cause the
policy to adjust, so the initial laziness has only warm up difference
from a theoretical expectation.

This optimization is useful when caches are sized as safety thresholds,
but in practice won't evict. In those cases the performance should be
close to the ideal using a ConcurrentHashMap, with the maximum size
penalty incurred only when deemed necessary. Note that the fastpath is
not enabled if access expiration or reference cache are configured.

The older and disabled fastpath approach was also removed. The idea had
been to avoid recording reads for the hottest entries to reduce the
contention on the read buffers. When the entry grew colder, that
optimization wouldn't apply and it would be bumped back up. Due to
Zipf-like distributions this seemed promising.

In benchmarks that approach didn't pan out. The reason was because it
reduced how quickly the read buffers filled up, which then do less work
by being lossy. It also created less predictable latencies as the
throughput would vary wildly between iterations. So it was worth the
experiment, but sadly didn't bare fruit.

This new approach shows good results in a laptop, so server workloads
should be nice. Extra care is needed in tests and benchmarks to ensure
the lazily initialized data structures are, in fact, initialized and
in a predictable state.

4279 of 4563 relevant lines covered (93.78%)

0.94 hits per line

Jobs
ID Job ID Ran Files Coverage
1 1553.1 (TERM=dumb) 07 Jan 2016 12:05PM UTC 0
93.78
Travis Job 1553.1
Source Files on build 1553
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #1553
  • 23ebe0f1 on github
  • Prev Build on master (#1552)
  • Next Build on master (#1554)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc