We had the author of LIRS come to Facebook last year to talk about his
algorithm and general benefits. At the time, we were looking at
increasing block cache efficiency. The general consensus was that it
wasn't an exponential perf gain, so we could get bigger wins from
cache-on-write
Engineer
Carrier IQ, www.carrieriq.com
e-mail: vrodio...@carrieriq.com
From: Nicolas Spiegelberg [nspiegelb...@fb.com]
Sent: Tuesday, February 21, 2012 9:01 AM
To: dev@hbase.apache.org
Subject: Re: LIRS cache as an alternative to LRU cache
We had the author
I thought about this over the summer when I was working on 4027.
Pretty much same idea as Nicholas here. I figured LIRs might be troublesome
to implement - and also thought that newer features, such as 4027 or the
reference counting patch, was a better use of time.
The larger the cache gets, the
: vrodio...@carrieriq.com
From: Nicolas Spiegelberg [nspiegelb...@fb.com]
Sent: Tuesday, February 21, 2012 9:01 AM
To: dev@hbase.apache.org
Subject: Re: LIRS cache as an alternative to LRU cache
We had the author of LIRS come to Facebook last year to talk about
From: Nicolas Spiegelberg [nspiegelb...@fb.com]
Sent: Tuesday, February 21, 2012 9:01 AM
To: dev@hbase.apache.org
Subject: Re: LIRS cache as an alternative to LRU cache
We had the author of LIRS come to Facebook last year to talk about his
algorithm and general benefits. At the time, we
Subject: Re: LIRS cache as an alternative to LRU cache
We had the author of LIRS come to Facebook last year to talk about his
algorithm and general benefits. At the time, we were looking at
increasing block cache efficiency. The general consensus was that it
wasn't an exponential perf gain, so
From: Nicolas Spiegelberg [nspiegelb...@fb.com]
Sent: Tuesday, February 21, 2012 9:01 AM
To: dev@hbase.apache.org
Subject: Re: LIRS cache as an alternative to LRU cache
We had the author of LIRS come to Facebook last year to talk about his
algorithm
