[Haskell-cafe] An interesting paper from Google

[Iustin Pop]

On Fri, Oct 15, 2010 at 11:08:14PM +0100, Andrew Coppin wrote:
>  On 15/10/2010 10:43 PM, Iustin Pop wrote:
> >On Fri, Oct 15, 2010 at 09:28:09PM +0100, Andrew Coppin wrote:
> >>I'm surprised about the profiler. They seem really, really impressed
> >>with it. Which is interesting to me, since I can never seen to get
> >>anything sensible out of it. It always seems to claim that my
> >>program is spending 80% of its runtime executing zipWith or
> >>something equally absurd.
> >I'm surprised that you're surprised :) The profiler is indeed awesome,
> >and in general I can manage to get one factor of magnitude speedup on my
> >initial algorithms, if not more.
> >
> >Even if it just tells me that zipWith is the slow part, that's enough.
> >I'd even say it's a very good hint where to start.
> 
> zipWith is a generic library function which always takes exactly the
> same amount of time. Unless you're using it so extensively that it's
> allocating huge amounts of memory or something, it would seem
> infinitely more likely that whatever function zipWith is *applying*
> should be the actual culprit, not zipWith itself.

I know about zipWith. And if the profile tells me I spend too much time
in zipWith, it means a few things:

- zipWith might have to force evaluation of the results, hence the
  incorrect attribution of costs
- if even after that zipWith is the culprit, it might be the way the
  lists are consumed (are they lazy-built?), and that might mean you
  just have to workaround that via a different algorithm

Again, the fact that it tells you time is being spent in a library
function is not bad, not at all.

> Of course, I'm talking about profiling in time. GHC also enables you
> to profile in space as well. I'm not actually sure to which one
> you're referring.

In general, time profiling. Although the space profiling is useful too,
it gives you hints on what the (lazy) program does, as opposed to what
you think it does. The retainer graphs are cool, e.g. you might see that
some code hangs on to data more than you fought, and you can save some
heap and GC time due to that.

> I haven't had much success with either. It's just
> too hard to figure out what the sea of numbers actually represent.
> (Since it's quite new, I'm assuming it's not the new ThreadScope
> functionallity - which I haven't tried yet, but looks extremely
> cool...)

I haven't used ThreadScope yet, but it's on my todo list.

iustin