ets vs list - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion ets vs list
Received-SPF: pass (google.com: domain of erlang-questions-return-53324-erlang-programming+garchive-81772=googlegroups....@erlang.org designates 193.180.168.22 as permitted sender) client-ip=193.180.168.22;
Mailing-List: contact erlang-questions-h...@erlang.org; run by ezmlm
Sender: <erlang-questi...@erlang.org>
Precedence: bulk
Message-ID: <4C8E5B52.9030...@amberbio.com>
Date: Mon, 13 Sep 2010 19:11:46 +0200
From: Morten Krogh <m...@amberbio.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: erlang-questi...@erlang.org
References: <AANLkTinX_L_KH3rUtTkG4dm4tYVNwvfSFVCqW8Ehf...@mail.gmail.com> <4C8E3541.7050...@erlang-solutions.com> <4C8E3826.30...@amberbio.com> <AANLkTikem5fM=u5o2N7=AS17ed=VBzvxvAaOb5yqp...@mail.gmail.com> <4C8E4041.1080...@amberbio.com> <4C8E46AA.9050...@erlang-solutions.com> <4C8E4CED.4040...@amberbio.com> <4C8E508D.3040...@erlang-solutions.com>
In-Reply-To: <4C8E508D.3040...@erlang-solutions.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [erlang-questions] ets vs list



Thanks. I just tried in the shell and saw that there were no new
processes after creating an ETS table. fine.

Surely, you could model ets with a process and message passing. Why
should it be slower? The only overhead should be the message passing.

So, I guess your benchmark might depend on the size of the key/value
pairs. For large values, the performance should be the same, for small
values the process might be a bit slower.

So, if we compare ets with dict or the process dictionary, then ets
should perform really badly on large values, it seems.

Suppose we have a giant list, that we store in the tables with some key,
i.e,  store(key) = [..,..,,,...............................]

If we want to traverse that list, dict and pd would start immediately,
whereas the list from ets would have to be copied before traversing
could start.

And after reading the list from ets it would have to be freed at the
next garbage collection, where as the dict and pd didn't generate any
garbage.

Morten.





On 9/13/10 6:25 PM, Ulf Wiger wrote:
> On 09/13/2010 06:10 PM, Morten Krogh wrote:
>>   Thanks again.
>>
>> My question might have been hard to understand because I made an
>> assumption that might be wrong, namely that
>> an ets table has a corresponding process. I don't mean the owning
>> process, but an implicit process that is spawned automatically
>> when the table is created, and that all insertions and deletions are
>> going through that process. Is that just my imagination?
>> Is an ets table only a hash table and nothing more? No corresponding
>> process that serializes all access to it? ETS:lookup is just a function
>> call, not a hidden
>> message pass, receive construct or what?
>>
>> Morten.
> ETS tables do not have a corresponding process (except for the
> temporary pseudo process during select()). Serialization is done
> with mutexes, so essentially, it's just a hash table or B-tree.
>
> That said, Erlang purists often hide behind the fact that you
> _could_ model ETS tables with processes and message passing
> (thus, process spawning and messaging are still the only
> means of side-effecting in Erlang ;-)
>
> It's not terribly difficult, but hard to do efficiently. The
> main issue is named tables, since you need a table registry,
> which implies another set of messages. I did this once (and
> as it happened, Robert V was doing the same thing at the same
> time - I was doing it for the Erlang Processor, and he was
> doing it for his own VM, VEE). As far as I recall, performance
> of my ETS emulation was ca 30x slower than regular ETS, at
> least on named tables*. :) This was many years ago, so the
> numbers may be completely different today.
>
> BR,
> Ulf W
>
> * But, as it happened, the Erlang Processor used ca 30x fewer
> clock cycles than my workstation to execute Erlang code, so
> ultimately I thought myself no worse off. :)
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
>


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
