[erlang-questions] Re: Best way to implement a simple cache
Matt Stancliff
sysop@REDACTED
Fri Nov 13 06:10:52 CET 2009
On Nov 12, 2009, at 5:17 PM, Thijs wrote:
> On Nov 13, 8:36 am, Scott Lystig Fritchie <fritc...@REDACTED>
> wrote:
>> ... except that public/protected ETS table access isn't free, either.
>> The VM has to play games with controlling multi-scheduler access to
>> ETS's underlying hash table/binary tree. I haven't measured with an
>
> You are right, but in my experience a public ETS table significantly
> outperforms process-mediated access. I'm curious how did you optimize
> this further?
Let's solve this with numbers!
Test || Multiplier || Percent Slowdown || Reads
Per Second
=
=
=
=
=
=
=
========================================================================
ets plain 1.00x 0%
553,384.3
ets public 1.01x 1%
550,329.3
ets public named table 1.10x 10%
502,504.7
mnesia ram copies 1.87x 87%
296,011.2
process based cache 9.86x 886%
56,141.6
BDB driver 56.37x 5,537%
9,816.3
While I have my benchmarking hat on, let's check function calls too:
Call Method || Multiplier || Percent Slowdown || Calls
Per Second
=
=
=
=
=
=
=
========================================================================
apply(?MODULE, foo, []) 1.00x 0%
96,089,747.8
?MODULE:foo() 1.01x 1%
94,809,477.4
foo() 1.09x 9%
88,485,052.9
fun() -> ok end() 3.15x 215%
30,489,431.6
apply(foo, []) 3.50x 250%
27,481,044.5
Module:Fun() 5.22x 422%
18,392,358.4
The slowest method of function invocation still yields 18+ million
calls per second.
Notes:
• Tests were run on my ancient (almost four year old) iMac (Core
Duo 2GHz):
Erlang R13B02 (erts-5.7.3) [source] [smp:2:2] [rq:2] [async-threads:0]
[kernel-poll:false]
• No scheduler binding to CPUs.
• For the function call benchmark: foo() -> ok. Module = ?MODULE,
Fun = foo.
• The "process based cache" is my fleshed out production version of
the duomark process cache.
Disclaimer: The results vary in absolute numbers for multiple runs of
the benchmark,
but results retain their relative positions in the rankings each time.
I'll get around to making a statistically valid erlang benchmark suite
one day.
-Matt
--
Matt Stancliff San Jose, CA
AIM: seijimr iPhone: 678-591-9337
"The best way to predict the future is to invent it." --Alan Kay
More information about the erlang-questions
mailing list