[erlang-questions] overhead of lists:dropwhile/2
Sun Apr 26 12:14:25 CEST 2015
On Sun, Apr 26, 2015 at 11:21 AM, Björn Gustavsson <bjorn@REDACTED> wrote:
> On Sat, Apr 25, 2015 at 3:10 PM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
> > While reviewing BjornG's compiler optimization in master, I've
> > noticed one pattern of optimization which at least to me isn't as
> > evident.
> I admit that the optimizations are tiny and that I have set a bad
> example by doing micro-optimizations.
> Don't try this at home! :-) lists:dropwhile/2 is a fine function and
> very rarely will you gain something by avoiding it.
Only if measurements show it to be a hot spot :).
> > I've reviewed the implementation of lists:dropwhile/2, and the
> > only difference I can see is that a call to the predicate fun is
> > avoided. Is that the - now removed - speed bump, or am I missing
> > something? If so, does it have to be a speed bump?
> You have missed the cost of building the fun that is passed to
> lists:dropwhile/2. If lists:dropwhile/2
I knew I missed something, and I might have probably noticed the
difference if I had compared Core Erlang. I'll try to remember that
the next time.
> drops many items from the list, that cost will not be noticeable.
> But it will be noticeable if no or few elements are dropped from the
> list. For example, in beam_utils, there is almost never any label to
> drop (i.e. the fun would only be called once for each call to
> lists:dropwhile/2). Similarly, in beam_jump it is also fairly common
> that nothing is dropped.
Would it be as fast if you had extracted the predicate into a local
fun and referenced it as "fun my_pred/1" in the dropwhile/2 call?
Can't we enable inlining per function?
More information about the erlang-questions