optimization questions

Gaspar Chilingarov <>
Tue May 9 10:38:42 CEST 2006

Hello, Richard!

Richard Carlsson wrote:
> Gaspar Chilingarov wrote:
>> Can erlang vm's gurus tell me which case is more efficient
>> R = size(Binary),
>> [ SomeFunction(R, X)  || X <- lists:seq(1, 1000) ]
>> or
>> [ SomeFunction(size(Binary), X)  || X <- lists:seq(1, 1000) ]
>> so - does compiler and vm understand that some parts of recursion are
>> constant and move their calculation outside of recursion or I should do
>> it by hand?
> The Beam compiler does not do that kind of optimization. But even if it
> was capable of hoisting computations out of a loop, it would also have
> to be able to prove that it does not change the behaviour of exceptions.
> For instance, if the call to lists:seq/1 crashes (maybe you've replaced
> the standard version with your own buggy implementation), then that
> exception must happen before the exception in size(Binary), if Binary
> turns out to be not a binary (or tuple). So, there's more work to it
> than you might think. Not impossible, just rarely worth the effort.

thanks a lot - I've seen C compilers doing such thing to loop variables
- at least Watcom sometimes done it.

>> Another issue - what if size(BInary) changed to ... say self() - I mean
>> that fetching binary size may be faster operation than creating variable
>> and accessing it every time.
> For self() there is no point keeping it in a variable. I did some quick
> measuring to settle this: In a *very tight* loop, it is slightly *slower*
> to keep an extra parameter than to call self() repeatedly, but the
> difference is only about 1-2 percent.
> For size(Binary), you must always pass at least one extra argument around
> the loop: either Binary itself, or a precomputed Size. In the same *very
> tight* loop as above, calling size/1 on each iteration is about 15% slower.
> Inserting some "real work" in each iteration will make this difference
> much smaller.
> Conclusion: don't manually hoist expressions that are O(1) unless you
> *know* that they have a significant time constant (relative to the context
> that you are using them in, of course). But if they ought to be hoisted,
> you need to do it yourself - the compiler does not do that for you.

It was not an optimization matter at first place, but just writing more
efficient code when writing it from scratch - just to make overall
performance a little bit higher.

Gaspar Chilingarov

System Administrator,
Network security consulting

t +37491 419763 (mob)
i 63174784

More information about the erlang-questions mailing list