[erlang-questions] overhead of lists:dropwhile/2

[Tuncer Ayaz]

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?