[Haskell-cafe] An interesting paper from Google

[Andrew Coppin]

  On 15/10/2010 11:18 PM, Iustin Pop wrote:
> 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.

I remember writing a long, complex program that was really slow. So I 
looked at the profile, and discovered that it was spending 98% of the 
runtime in... Prelude.floor?! o_O I thought maybe the costs were just 
being mis-attributed. But on replacing Prelude.floor with some dark, 
mysterious GHC primitives, my program's runtime went from minues to 
milliseconds.

So, yeah, profiling can sometimes help you to discover where the time is 
_really_ being spent, not where you _think_ it's being spent. (I would 
have expected the long complex numerical algorithm to be eating cycles, 
not a trivial conversion from floating-point to integers.) But 
personally, I usually find it almost intractably difficult to figure out 
precisely what's going on by looking at a time profile. (Maybe that says 
more about me than about GHC's time profiler...)

>> 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.

Again, I have great difficulty figuring out exactly what the numbers 
mean. But it's definitely nice that GHC can spit out all these 
statistics for you just by recompiling your program. (Shame it slows 
down to a crawl, but I guess that's rather unavoidable...) Knowing how 
much GC time you're using is especially invaluable.

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

Yeah, that does look like an extremely cool piece of equipment. I hope 
they start adding things like space profiling and so forth to the same 
infrastructure. (As I understand it, they're intending to do so, it's 
just a question of developer time...)