Difference between revisions of "Talk:Performance/Laziness"
m |
|||
| Line 1: | Line 1: | ||
i'm just glancing, but shouldn't it be: "evens (x:_:xs) = x : evens xs" ? --[[User:JohannesAhlmann|Johannes Ahlmann]] 01:54, 23 July 2006 (UTC) |
i'm just glancing, but shouldn't it be: "evens (x:_:xs) = x : evens xs" ? --[[User:JohannesAhlmann|Johannes Ahlmann]] 01:54, 23 July 2006 (UTC) |
||
| + | |||
| + | ---- |
||
| + | |||
| + | i was hoping for a more in-depth tutorial on how to use laziness to write more performant code. freenode channel folks say there are 2 ways to get performance: make your code more strict, or more lazy. and often the latter leads to cleaner code. i'd like to see more concrete examples of that. what's currently on this page just explains how laziness can avoid work - of course this is a performance gain, but i'm referring to when the work has to be done anyway (they even conclude with such a situation, merge_sort). aren't there any other advantages to laziness, sharing, etc.? |
||
| + | |||
| + | anyway, as a newbie, i'm already getting the impression that haskell performance is tricky. from http://www.algorithm.com.au/mt/haskell/haskells_performance.html: |
||
| + | |||
| + | "For optimisation, you must know what factors are causing things to be slow, otherwise you’ll be searching in the dark for what bits to optimise. So, Haskell users will tell you to profile (which is sound advice no matter what language you’re using). That’s fine. The problem then is you have to know why something is slow, and there’s where Haskell can get complex. Is there a space leak? (Do you even know what a space leak is?) Is your array strict instead of lazy? If it’s strict, is it boxed instead of unboxed? (Do you even know what unboxing is?) Can you use unsafeRead instead of readArray? (Did you know that unsafeRead exists? I sure didn’t!)" |
||
| + | |||
| + | --[[User:Yang|Yang]] 13:32, 8 October 2006 (UTC) |
||
Latest revision as of 13:32, 8 October 2006
i'm just glancing, but shouldn't it be: "evens (x:_:xs) = x : evens xs" ? --Johannes Ahlmann 01:54, 23 July 2006 (UTC)
i was hoping for a more in-depth tutorial on how to use laziness to write more performant code. freenode channel folks say there are 2 ways to get performance: make your code more strict, or more lazy. and often the latter leads to cleaner code. i'd like to see more concrete examples of that. what's currently on this page just explains how laziness can avoid work - of course this is a performance gain, but i'm referring to when the work has to be done anyway (they even conclude with such a situation, merge_sort). aren't there any other advantages to laziness, sharing, etc.?
anyway, as a newbie, i'm already getting the impression that haskell performance is tricky. from http://www.algorithm.com.au/mt/haskell/haskells_performance.html:
"For optimisation, you must know what factors are causing things to be slow, otherwise you’ll be searching in the dark for what bits to optimise. So, Haskell users will tell you to profile (which is sound advice no matter what language you’re using). That’s fine. The problem then is you have to know why something is slow, and there’s where Haskell can get complex. Is there a space leak? (Do you even know what a space leak is?) Is your array strict instead of lazy? If it’s strict, is it boxed instead of unboxed? (Do you even know what unboxing is?) Can you use unsafeRead instead of readArray? (Did you know that unsafeRead exists? I sure didn’t!)"
--Yang 13:32, 8 October 2006 (UTC)