A related question, for code like following:<div><div>test(<<255, T/binary>>) -></div><div>    ok;</div><div>test(<<_, T/binary>>) -></div><div>    test(T).</div><div><br></div><div>Does Erlang copy the input binary for each recursion? If the input is huge, it would be very low efficient. If so, what should we do?</div>

<div><br></div><div>Thanks</div><div>Andy</div><div><br><div class="gmail_quote">On Wed, Jun 1, 2011 at 3:28 AM, Paul Meier <span dir="ltr"><<a href="mailto:pablo.a.meier@gmail.com">pablo.a.meier@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'm in a similar situation.  I've got a few large tries, implemented<br>
with gb_trees.  I keep them in an orddict, which I'm using as the<br>
State variable of a gb_server.  For example:<br>
<br>
------<br>
init() -><br>
    %% State is an orddict of 3 giant Tries, pre-made and fetched from<br>
the filesystem.<br>
    {ok, State}.<br>
<br>
handle_call({keyed_operation_on_large_data, Key}, _From, State) -><br>
    GiantTrie = orddict:find(Key, State),<br>
    .... computations using GiantTrie....<br>
    {reply, Result, State}.<br>
<br>
I'm finding that my process is crashing due to inability to mmap, and<br>
the erl_crash.dump file tells me that the gen_server's supervisor (or,<br>
on occasion, the error_logger) is the one with a prohibitively large<br>
Stack+Heap.  Also, I never modify the Tries or the orddict containing<br>
them in calls to the gb_server: it's all read-only.<br>
<br>
Is storing the value in an orddict, or using regular terms as opposed<br>
to binaries causing unnecessary copying?  While _I_ know the data is<br>
being used in a read-only fashion, is there a place where copying<br>
might be occurring because the VM doesn't know this?<br>
<br>
I was hoping to play with binaries as a next attempt at fixing this<br>
(the links in this thread suggest that large binaries are handled more<br>
conservatively), but this thread appeared fortuitously, and maybe<br>
someone can spot the very likely obvious error that I'm making.<br>
<br>
I'm grateful for your help, whether in this thread or the others I've<br>
enjoyed reading ^_^<br>
<font color="#888888"><br>
-Paul<br>
</font><div><div></div><div class="h5"><br>
<br>
On Tue, May 31, 2011 at 11:19 AM, Kostis Sagonas <<a href="mailto:kostis@cs.ntua.gr">kostis@cs.ntua.gr</a>> wrote:<br>
> Robert Virding wrote:<br>
>><br>
>> I just want to point out that these rules are BEAM specific and not Erlang<br>
>> specific.<br>
><br>
> Well, this is not correct: the BEAM nowhere specifies that its instruction<br>
> set has to be implemented using a private heap architecture.  In fact, we<br>
> successfully used the BEAM instruction set to implement both a shared heap<br>
> and a hybrid heap implementation.  See:<br>
><br>
>  <a href="http://user.it.uu.se/~kostis/Papers/heap.pdf" target="_blank">http://user.it.uu.se/~kostis/Papers/heap.pdf</a><br>
><br>
>> So on an implementation with a single heap all data is shared. Now there<br>
>> aren't currently many single heap implementations, to be exact only one,<br>
>> erjang (Erlang on the JVM). :-)<br>
><br>
> There have been more.  We had an OTP system with a shared heap and the<br>
> hybrid heap system was part of OTP for quite a while.  IMO, it's too bad<br>
> that it was not maintained when Erlang/OTP was extended to support SMP<br>
> architectures.<br>
><br>
> Also, the ETOS (Erlang to Scheme) system was based on a shared heap<br>
> architecture.<br>
><br>
> Kostis<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>