[erlang-questions] byte_size/1 vs variable access

Loïc Hoguin essen@REDACTED
Wed Feb 26 14:39:00 CET 2014


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



More information about the erlang-questions mailing list