[erlang-questions] binary optimization

[Mikael Pettersson]

Joel Reymont writes:
 > 
 > On Jul 18, 2009, at 12:41 PM, Mikael Pettersson wrote:
 > 
 > > In this code, either enumerate the possible values for Where and
 > > invoke them via an explicit case expression, or specialise  
 > > handle_info/3
 > > into a set of handle_info_.../2 functions, one for each possible  
 > > Where.
 > 
 > What exactly (and how much) would I be buying with this restructuring?
 > 
 > Would I be avoiding duplicating the binary, i.e. extra memory  
 > allocation?

That depends entirely on the nature of the callees. If they require
converting the delayed sub binary to a proper term, then you won't
save anything for that piece of the state. On the other hand, if they
don't then yes you'd save some memory allocation.

 > Is there anything else?

Calls to code which isn't known at compile-time are always expensive,
both because they limit what optimisations the compiler can do, and
because they require additional type checks or lookups at runtime.

 > What is a delayed sub-binary representation? Is there a paper on this?

None that I know of. Basically, a binary is a full-blown term. A sub-binary
is a binary constructed as a sub-segment of a binary, which allows the
sub-binary to be represented as a small wrapper term containing a reference
to the original big binary. A delayed sub-binary, presumably, is a sub-binary
represented by a set of registers in the generated code. That's possible as
long as the compiler can see all accesses to that sub-binary. However, the
instant that delayed sub-binary "escapes" (is returned, passed to unknown code,
or stored in an aggregate), it must be converted to a full-blown proper term,
i.e. be allocated on the heap.

Björn is the expert on this stuff.

 > > A possible solution is to change send/3 to send/4
 > > with Token as an additional parameter, and then hope that send/4 is  
 > > nice
 > > enough so that the compiler can keep Token in its delayed sub binary
 > > representation.
 > 
 > 
 > Well, I do want to keep the token around in the state of the gen_server.
 > I guess converting to send/4 is not gonna buy me anything since I will
 > need to stuff Token into State in send/4. Am I right?

Yes, stuffing Token into State makes it escape, requiring it to be
converted to a full-blown term.