[erlang-questions] immutable benefits

[Henning Diedrich]

So with the benefits being in fact as big as I had hoped for, I am 
wondering if I am getting this right: binary scans do indeed cascade 
down several levels and may all end up pointing to the same source chunk 
of memory?

Plowing through the manual, what I am understanding is this (great news):
**
*With Erlang you get for free that you (often) don't duplicate any 
contents at all when parsing binaries. *Although you may end up having a 
lot of variables. But they often all share the same contents buffer.

You do have the time consumption of the parsing of course. But all that 
happens is that pointers into the binary are created. Nothing is copied.

(See pg. 168+ Erlang/OTP System Documentation)

Concretely, it does not copy the names /*Name*/ out of the source binary 
_*Bin*_ but only sets pointers into _*Bin*_ to populate the /*Name*/s.

        erl_table(<<Length:16, MetaLength:16, Status:16, Count:16,
        /*Stream*/>>=_*Bin*_) ->

            ...

            <<TypeBinaries:Count/binary,
               /*NamesBinary*/:NameStringSpace/binary,
               EntryCount:16,
               EntryBinary/binary>> = _*Stream*_,
           
               ...
             
               % List comprehension from a binary generator:
               Names = [ Name || <<Size:16, /*Name*/:Size/binary>> <=
        _*NamesBinary*_ ].

If I understand correctly, this leaves me with the individual /*Name 
*/variables internally being but pointers into the original binary 
buffer of _*Bin*_* (*first line)?

Thanks,
Henning


Henning Diedrich wrote:
> Thanks for heads up, now reading ...
>
> http://www.erlang.org/doc/efficiency_guide/introduction.html
> - or - http://www.erlang.org/doc/pdf/otp-system-documentation.pdf pg 
> 164 ...
>
> And what part is not yet implemented?
>
> Max Lapshin wrote:
>> "Erlang performance" part of documentation tells us, that this code
>> will create two subbinaries, that are pointing into refcounted large
>> binary.
>>
>> For example, this way is excelent for mmap-reading of files, but it is
>> not yet implemented.
>>
>>   
>
>