On Fri, May 8, 2009 at 2:37 PM, Andrew Coppin <andrewcop...@btinternet.com>wrote:
> John Lask wrote: > >> on the other hand a function to release pool memory to the OS down to the >> current active level should (I hope) be easily implementable, and quickly >> incorporated into application where required, whereas arriving at one or >> more automatic deallocation policies would most likely require some >> analysis/trial and error. >> > > I would suggest that trying to do this "automatically" in a way that is > optimal for all applications requires some fairly serious heuristics. > > OTOH, for many Haskell programs it isn't a problem in the first place. > (E.g., if you write something like Darcs which only ever runs for a few > seconds, you barely need GC in the first place.) That's not entirely true. Darcs has a fair number of operations that stream data and hence work well because the RTS can recycle the memory and keep the usage at a constant. I think I see your point and agree in principle though. A similar argument can be applied to laziness. Often times you end up evaluating most or all of the thunks, so what difference did it make? But, I guess it's a bit of an oversimplification in both cases. > I'm just thinking, the application writer probably knows more about their > specific program than the compiler designers do, so it would be nice to be > able to provide hints to the RTS. Definitely. Jason
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe