[erlang-questions] ets:lookup() versus mnesia:ets()

Ulf Wiger (TN/EAB) ulf.wiger@REDACTED
Thu May 10 18:13:18 CEST 2007


Sure, it has been done. You seem to be aware of 
the drawbacks.

mnesia:ets(fun/0) was created to avoid this very
thing, assuming that it wouldn't matter for most
people that it'd cost a couple of micros extra.

Even better than mnesia:ets/1 is to use 

mnesia:activity(Type, fun/0),

where Type can be set to ets, async_dirty, sync_dirty,
etc., giving you a wider array of dirtiness to choose

Ulf W 

> -----Original Message-----
> From: erlang-questions-bounces@REDACTED 
> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of 
> Paulo Sérgio Almeida
> Sent: den 10 maj 2007 16:59
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] ets:lookup() versus mnesia:ets()
> Hi all,
> I know this is a sacrilege, breaking all rules of 
> abstraction, assuming some internals of the implementation, 
> bla, bla, bla, ... ;)
> But ... suppose that it is important to squeeze the last bit 
> of performance and, in a scenario where I wanted to do reads 
> on a non-replicated disc_copies mnesia table, of records that 
> are only updated by the same process (even though other 
> processes update other records), and where I use:
> mnesia:ets(fun()-> mnesia:read({Table, Key}) end)
> and therefore have the lowest access context / isolation 
> level available and I am happy with it. Is there anything 
> that could go wrong if I instead used:
> ets:lookup(Table, Key)
> This would save building the closure, and the tests that read 
> must make to figure out the access context, and it can be 
> twice as fast in a set table (I measured 2 microseconds 
> instead of 4 on my notebook; mnesia:dirty_read is slower, 
> taking 5 microseconds).
> So, is there any problem switching from mnesia:ets to 
> ets:lookup in this scenario? Has such a thing crossed anyone's mind?
> Paulo Almeida
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list