[Haskell-cafe] An interesting paper from Google

[Brandon S Allbery KF8NH]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/18/10 21:37 , Evan Laforge wrote:
> For instance, currently I have the top consumer of both time and alloc
> as 'get', which is 'lift . Monad.State.Strict.get'.  Of course it
> occurs in a million places in the complete profile, along with
> mysteries like a line with 0 entries 0.7%/0.1 time/alloc.  Doesn't 0
> entries mean it was never called?  Meanwhile, a line with 37000
> entries has 0.2/0.2.  Is the difference how the 'get'ed value was
> used?  And then there's the wider question of how 'get' is taking so
> much time and space.  Doesn't it just return a pointer to the State
> value?  Biographical profiling shows large amounts of void, lag, and
> drag, but no clear way to trace that to the code that is responsible.

Any time you see something "inexplicable" like lots of time being attributed
to something simple like "get", it means that something isn't strict enough
and "get" is having to force a bunch of lazy evaluations to do its job.
Since you're using State.Strict but lift-ing to get there, I'd first look at
the strictness of the monad you're lift-ing from.  (I'm assuming
State.Strict does what the label says, but it's possible that it's not
strict in the way you need; strictness is kinda tricky.)

Moral of the story:  time is accounted to the function that forces
evaluation of lazy thunks, not to the thunks themselves or the function that
created the lazy thunks.  (I think the latter is impossible without passing
around a lot of expensive baggage, and in any case doesn't tell you anything
useful; unexpected functions taking a lot of time, on the other hand, tells
you right away that there's excessive laziness in the invocation somewhere
and gives you a starting point to track it down.)

- -- 
brandon s. allbery     [linux,solaris,freebsd,perl]      allbery at kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university      KF8NH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAky9zQ8ACgkQIn7hlCsL25UvhACeIGaziKg+nx6cTWRLnwjf0T5c
Gg8An1ZvNSDj/NXh032wsTGWZjLxZ7xD
=VPo+
-----END PGP SIGNATURE-----