[erlang-questions] binary optimization
Sat Jul 18 15:03:32 CEST 2009
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
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.
More information about the erlang-questions