Timing execution of individual functions in ghci?
When playing around with various implementations of a single function it would be nice to time the execution. Is there some way to do that easily from within GHCi? Or am I forced to look to criterion for that? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete
On Wed, Oct 22, 2014 at 6:05 AM, Magnus Therning
When playing around with various implementations of a single function it would be nice to time the execution. Is there some way to do that easily from within GHCi?
:set +s (possibly also +r; http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-set.html#idp732... ) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
Hi Magnus,
When playing around with various implementations of a single function it would be nice to time the execution. Is there some way to do that easily from within GHCi?
ghci normally only interprets your code, without much optimizations, so your timings might be quite misleading.
Or am I forced to look to criterion for that?
I think so, if you want to trust your timings. Greetings, Daniel
On Wed, Oct 22, 2014 at 12:48:53PM +0200, Daniel Trstenjak wrote:
Hi Magnus,
When playing around with various implementations of a single function it would be nice to time the execution. Is there some way to do that easily from within GHCi?
ghci normally only interprets your code, without much optimizations, so your timings might be quite misleading.
Well, it might be enough to confirm or disprove intuitions about time complexity of an implementation; is it O(n) or O(n^2)? And that's really what I'd like to see at a first step. Given that all I'm interested in is relative timings it might even be enough to do a rough comparison of two implementations too.
Or am I forced to look to criterion for that?
I think so, if you want to trust your timings.
It's just a bit too much ceremony when all I want is to confirm that "inserting in reversed order followed by a `reverse`" has less time complexity than "repeated appending." Of course the only way to get something I can take to the bank is using criterion. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete
Hi Magnus,
Given that all I'm interested in is relative timings it might even be enough to do a rough comparison of two implementations too.
Optimizations - especially in Haskell - can change the runtime behaviour quite dramatically. So comparing the runtime performance without turned on optimizations is pretty much pointless. Meaningful benchmarking is hard and adding any kind of uncertainty doesn't make it in any way easier. Greetings, Daniel
indeed. My suggestion is 1) use criterion, its awsome 2) run the criterion suite with a variety of optimization flag choices so you can understand how that changes performance 3) use criterion some more ! On Thu, Oct 23, 2014 at 10:35 AM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:
Hi Magnus,
Given that all I'm interested in is relative timings it might even be enough to do a rough comparison of two implementations too.
Optimizations - especially in Haskell - can change the runtime behaviour quite dramatically. So comparing the runtime performance without turned on optimizations is pretty much pointless.
Meaningful benchmarking is hard and adding any kind of uncertainty doesn't make it in any way easier.
Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
While criterion is really great, sometimes you do just want to measure timings. For that, you might want to give my package chronograph ( http://hackage.haskell.org/package/chronograph) a try. On Thu, Oct 23, 2014 at 10:40 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
indeed. My suggestion is 1) use criterion, its awsome 2) run the criterion suite with a variety of optimization flag choices so you can understand how that changes performance 3) use criterion some more !
On Thu, Oct 23, 2014 at 10:35 AM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:
Hi Magnus,
Given that all I'm interested in is relative timings it might even be enough to do a rough comparison of two implementations too.
Optimizations - especially in Haskell - can change the runtime behaviour quite dramatically. So comparing the runtime performance without turned on optimizations is pretty much pointless.
Meaningful benchmarking is hard and adding any kind of uncertainty doesn't make it in any way easier.
Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (5)
-
Brandon Allbery -
Carter Schonwald -
Daniel Trstenjak -
John Lato -
Magnus Therning