|
ETS keys: how complex in usual cases?: msg#00370lang.erlang.general
I've been pondering some wacky things lately regarding the keys used for ETS tables. It's possible to use any term as a record's key in an ETS table, but how often is that ability *really* used? Would it be useful to be able to limit the type of term used for an ETS table key if it meant a performance increase? I'd add another option to ets:new(): {keyfmt, Term}. "Term" would be a representative key, examples being: 1, foo, "foo", <<"foo">>, {foo, bar}, and {foo, 1} To illustrate the point using the last example, {foo, 1}, all keys inserted into the table must be a tuple of arity 2 where the first element must be an atom and the second element must be a number. I'm still trying to figure out if I can make my little idea is even feasible. If I can get it to work, the speed improvement may be 15% to possibly 30-35% for very large ETS tables. Would that be worth it? Does Mnesia do anything to its ETS tables that would screw up such a restriction? -Scott |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: testing codes in erl with running processes: 00370, Matthias Lang |
|---|---|
| Next by Date: | Re: ETS keys: how complex in usual cases?: 00370, Scott Lystig Fritchie |
| Previous by Thread: | prolog like operation in erlang ?i: 00370, HP Wei |
| Next by Thread: | Re: ETS keys: how complex in usual cases?: 00370, Scott Lystig Fritchie |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |