[erlang-questions] byte_size/1 vs variable access

[Fred Hebert]

Everything is immutable, but it is not side-effect free. Twot hings to
consider:

- Only allowing it in guards to avoid side-effects that could be
  triggered at the wrong moment. If you allow it with any code, then
  multiple function calls being moved around can change the number of
  messages sent or received within that function
- Messing up tracing of function calls where the file and the resulting
  code no longer match, breaking expectations.

On 02/26, Loïc Hoguin wrote:
> What I want is to write the most readable code possible and that the
> compiler makes it run as fast as possible, using hints that could be
> provided in the form of compiler flags (possibly local to a module). It's
> pretty much already what the compiler is doing with other things.
> 
> I understand I can't defer everything to the compiler, but considering
> Erlang is immutable it shouldn't be too hard to automate that kind of
> optimization, and be allowed to write tighter and cleaner code while still
> having these tiny improvements.
> 
> On 02/26/2014 02:23 PM, Aidan Hobson Sayers wrote:
> >If your performance is on a knife edge such that var lookup vs bif call
> >is important then perhaps you wouldn't want the compiler to blindly
> >perform this optimisation?
> >E.g. if your first clause happens in (say) 99% of cases and the compiler
> >tries to be clever, you're doing
> >  - bif call
> >  - variable store
> >  - variable access
> >when maybe you'd rather it do the multiple bif calls if it had to
> >because 99% of the time it only needs to do one.
> >
> >But that would depend on how much faster var access is compared to the
> >bif call. If it's 2x faster you definitely don't want the 'optimisation'
> >above all the time. If it's 1000x faster then you want this optimisation
> >for the 99% of the time case above...but not if the first clause happens
> >99.999% of the time.
> >
> >As with all things performance, benchmarks are the only solution.
> >
> >Aidan
> >
> >
> >On 26 February 2014 12:42, Loïc Hoguin <essen@REDACTED
> ><mailto:essen@REDACTED>> wrote:
> >
> >    Thanks.
> >
> >    Is there any optimization when it's done inside a function clause
> >    guard? For example say, 5 of my 6 clauses need to check
> >    byte_size(Bin) to decide what to do. I am reading some code I wrote
> >    a few days ago and I see I instinctively used a single clause,
> >    creating a variable to hold the size and then used a if inside it.
> >    Perhaps the compiler is doing something about it in this case?
> >
> >    I know it doesn't matter 99% of the time, but I got one or two
> >    modules that deal with binaries where the smallest improvement means
> >    I can handle a bunch more traffic. To be honest it would be really
> >    nice if the compiler would automatically create a variable when it
> >    sees me use byte_size/1 more than once as I can then stop writing
> >    all this extra code. And I'm guessing it could probably do the same
> >    with length/1 and others.
> >
> >
> >    On 02/26/2014 12:46 PM, Björn Gustavsson wrote:
> >
> >        On Tue, Feb 25, 2014 at 10:56 PM, Loïc Hoguin
> >        <essen@REDACTED <mailto:essen@REDACTED>> wrote:
> >
> >            But considering byte_size/1 is O(1) I am wondering if
> >            perhaps that's a
> >            little pointless. Is it even worth creating a variable for
> >            this? Is perhaps
> >            the variable optimized out? Perhaps accessing a variable
> >            contents and
> >            calling byte_size/1 are equivalent operations? Or the GC
> >            that will follow is
> >            not worth what little is saved by creating a variable in the
> >            first place?
> >
> >            If someone could shed some light on this perhaps I could
> >            stop creating
> >            variables like this and simplify my code a little more.
> >
> >
> >        There is definitely more overhead calling a BIF than accessing a
> >        variable.
> >
> >        That said, I doubt that you will be able to notice the
> >        difference in a
> >        real program.
> >        So I suggest that you write in the way that you find most readable.
> >
> >        /Bjorn
> >
> >
> >    --
> >    Loïc Hoguin
> >    http://ninenines.eu
> >
> >    _________________________________________________
> >    erlang-questions mailing list
> >    erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> >    http://erlang.org/mailman/__listinfo/erlang-questions
> >    <http://erlang.org/mailman/listinfo/erlang-questions>
> >
> >
> 
> -- 
> Loïc Hoguin
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions