> This works fine of course but now I am trying to understand > the meaning of this (optional) compiler warning:
> Warning: INFO: using a matched out sub binary will prevent > delayed sub binary optimization
> How should I interpret this warning?
The compiler and VM is smart and optimises the matching of a binary where the last segment is a binary. This makes it more efficient to use a binary like a list and pick things off the front.
*BUT* for this to work the reference to the whole binary, Bin your case, must not be used after the match, then the compiler can reuse that binary reference and save work. You reuse Bin and the compiler is warning you that when you do this it can't do a good a job as possible.
My thinking was that reading a big binary and then passing it with offsets to various parsing functions would be easier on the emulator than creating a new binary for each one. Is it the case that the compiler will optimize away the creation of these binaries?
-Vance
On Mon, Nov 24, 2008 at 08:10:38PM +0100, Robert Virding wrote: } The compiler and VM is smart and optimises the matching of a binary where } the last segment is a binary. This makes it more efficient to use a binary } like a list and pick things off the front. } } *BUT* for this to work the reference to the whole binary, Bin your case, } must not be used after the match, then the compiler can reuse that binary } reference and save work. You reuse Bin and the compiler is warning you that } when you do this it can't do a good a job as possible.
> My thinking was that reading a big binary and then passing it > with offsets to various parsing functions would be easier on > the emulator than creating a new binary for each one. Is it > the case that the compiler will optimize away the creation of > these binaries?
No, I don't think so. It optimises the following case:
The important thing is that the old reference to the binary is not used again and can be reused by the compiler. If you have a big binary and want to pass off chunks of it to different functions is a different problem. Then it is probably better to pass the whole binary and an offset. However, doing something like:
On Mon, Nov 24, 2008 at 11:27 AM, Vance Shipley <van...@motivity.ca> wrote: > Robert,
> My thinking was that reading a big binary and then passing it > with offsets to various parsing functions would be easier on > the emulator than creating a new binary for each one. Is it > the case that the compiler will optimize away the creation of > these binaries?
> -Vance
> On Mon, Nov 24, 2008 at 08:10:38PM +0100, Robert Virding wrote: > } The compiler and VM is smart and optimises the matching of a binary where > } the last segment is a binary. This makes it more efficient to use a binary > } like a list and pick things off the front. > } > } *BUT* for this to work the reference to the whole binary, Bin your case, > } must not be used after the match, then the compiler can reuse that binary > } reference and save work. You reuse Bin and the compiler is warning you that > } when you do this it can't do a good a job as possible. > _______________________________________________ > erlang-questions mailing list > erlang-questi...@erlang.org > http://www.erlang.org/mailman/listinfo/erlang-questions
Follow-up question to the converse problem: assembling binaries. If binaries are best handled like lists while reading them, is it also true that binaries are best assembled back-to-front like lists, putting the new binary chunk onto the beginning of the binary instead of the end?
_____
From: erlang-questions-boun...@erlang.org [mailto:erlang-questions-boun...@erlang.org] On Behalf Of Robert Virding Sent: Monday, November 24, 2008 13:58 To: Vance Shipley; Robert Virding; Erlang Questions Subject: Re: [erlang-questions] Binary pattern matching and optimization
My thinking was that reading a big binary and then passing it with offsets to various parsing functions would be easier on the emulator than creating a new binary for each one. Is it the case that the compiler will optimize away the creation of these binaries?
No, I don't think so. It optimises the following case:
The important thing is that the old reference to the binary is not used again and can be reused by the compiler. If you have a big binary and want to pass off chunks of it to different functions is a different problem. Then it is probably better to pass the whole binary and an offset. However, doing something like:
On Mon, Nov 24, 2008 at 04:04:26PM -0600, David Mercer wrote: } Follow-up question to the converse problem: assembling binaries. If } binaries are best handled like lists while reading them, is it also true } that binaries are best assembled back-to-front like lists, putting the new } binary chunk onto the beginning of the binary instead of the end?
That is very good indeed. I kind of felt a pang of guilt in posting my questio, because I thought I should test before asking, so I could see for myself, but really, I ought to have looked in the docs. Thanks, Vance.
> On Mon, Nov 24, 2008 at 04:04:26PM -0600, David Mercer wrote: > } Follow-up question to the converse problem: assembling binaries. If > } binaries are best handled like lists while reading them, is it also > true > } that binaries are best assembled back-to-front like lists, putting the > new > } binary chunk onto the beginning of the binary instead of the end?
