[erlang-questions] fprof overestimate the cost of list comprehension ?

[zxq9]

On 2016年7月5日 火曜日 10:31:34 Zhongzheng Liu wrote:
> Hi mail list:
> 
> I profiled my program and found the performance of tail recursion and
> reverse is always better than list comprehension in fprof. I feel strange
> after reading the discuss in mail list <
> http://erlang.org/pipermail/erlang-questions/2016-June/089479.html> and
> wrote a small test myself.
> 
> The result showed that list comprehension run faster in timer:tc/3, but
> slower in fprof.
> 
> I think the result of timer:tc/3 is more believable and fprof is
> overestimate the cost of list comprehension. This will be misleading when I
> do performance optimization guided by fprof.
> 
> Why it happens and how to correct the result of fprof?

Be careful how much faith you put in microbenchmarks like this outside
any actual operational context. Expressiveness is dramatically more
important than whether the iteration mechanism X is slightly faster
than occasionally-equivalent mechanism Y. Iteration itself is nearly
always dwarfed by the actual computation that is taking place,
especially if there is a side-effect involved.

As far as timer:tc VS fprof... they are two different tools designed to
do two very different things. One gives you a very rough (often uselessly
rough) way to turn almost any call into a microbenchmark (slick, but not
really where the useful part of testing resides as far as your users are
ever concerned), the other gives you a system-sized profile of where your
program is spending its time. Its not even apples to oranges, more like
comparing oats to quarterhorses.

As for *why* the discrepancy... It probably has to do with fprof using
trace, and timer:tc just executing something and telling you the time
diff. A lot more steps are involved in tracing to get an execution
profile. One of the interesting differences is that when profiling you
*don't care* how *long* something took as measured by the wall clock.

Be wary of microbenchmarks.

-Craig