I *think* I understand about lazy evaluation and its effects on I/O and that it can internally create thunks, promises, continuations etc. whatever you want to call them, and then at some point there will be a sudden spike in memory and CPU loads as something triggers a whole chain of promises to be fulfilled but what I don't have a feel for is just how serious a problem that might be today in say, a simple desktop application. For example, let's just say I write a simple application in 'C' and a comparable one in Haskell both running on the same hardware, but not concurrently! Would the Haskell one ever find itself running out of memory given the same input sequence as the 'C' program because of the way it works ? I know that the 'C' one could also run out of memory but I hope that the sentiment of my question is clear; what are the ramifications, gotchas and other considerations that using a purely functional lazy language like Haskell you need to be aware of when coming from an imperative / scripted background ? Notwithstanding the fact that there are strict flavours of functions that can be used.... but only if you are truly aware of the reasons for their existence in the first place, is this a real design issue to consider when coding an application in Haskell or is it only for certain 'groups' of applications. I guess the nature of the application would be the governing factor. Is it something one needs to worry about at all or should one just code away and write the application and then worry!? I think that having a clearer understanding of what 'types' of problems and their implementations have on CPU/RAM would be a good one to have! :) Thanks Sean Charles.
Sean Charles wrote:
I *think* I understand about lazy evaluation and its effects on I/O and that it can internally create thunks, promises, continuations etc. whatever you want to call them, and then at some point there will be a sudden spike in memory and CPU loads as something triggers a whole chain of promises to be fulfilled but what I don't have a feel for is just how serious a problem that might be today in say, a simple desktop application.
[...]
Is it something one needs to worry about at all or should one just code away and write the application and then worry!?
I think that having a clearer understanding of what 'types' of problems and their implementations have on CPU/RAM would be a good one to have!
The practitioner's approach to laziness is usually the following sequence of approximations, which could be called "the lazy approach to laziness": 0) Don't worry about performance. Write programs that are correct instead. Laziness helps a lot with writing clean and compositional code. Example: zipWith (,) [1..] xs 1) Look out for common laziness gotchas. There are essentially only two of them: i) Unevaluated expressions that take way more space than their evaluated forms. Prototypical example foldl (+) [1..n] ii) Memory leaks due to sharing. Prototypical example average xs = sum xs / length xs 2) Don't worry about memory leaks until they actually appear. If they do, use a profiling tool to find out what's going on. Most likely, one of the two things above happened in an interesting way. Note that you might want to be a bit more careful when writing a real time system. In that case, would suggest to only use abstractions whose performance is easy to reason about and to keep the core code fairly small, so that you have a clear picture of what is going on. Other than that, there is no need to worry about garbage collection or laziness. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
On Sat, 19 Mar 2011 12:50:18 +0100, Heinrich Apfelmus
2) Don't worry about memory leaks until they actually appear. If they do, use a profiling tool to find out what's going on. Most likely, one of the two things above happened in an interesting way.
It is likely that, if you develop a medium to large sized application for a customer, memory leaks will appear at the customers site. It will often be very difficult to reproduce the situation and find the leak. If you want to produce quality software, it is best to be sure what you are doing during the whole development process. There should be a set of guidelines, on how to prevent space leaks. See also "On the reliability of programs", http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --
participants (3)
-
Heinrich Apfelmus -
Henk-Jan van Tuyl -
Sean Charles