On Mon, Jan 16, 2006 at 05:21:15PM +0100, Juliusz Chroboczek wrote: > > I suspect that there is also a space leak in gzReadPatchFileLazily. > > ``Retainer'' is the politically-correct term in Haskell-land. > > > Who knows, I've looked at it some, but I'm making little or no > > progress and the trouble shooting feels like voodoo so far (just > > making changes without an understanding). > > Use GHC's space profiler, which unlike the time profiler appears to be > reasonably reliable.
It sometimes does still change behaviour though, sadly; hence the filtering out of -auto-all flags for some modules near the top of GNUmakefile. > and run hp2ps on the resulting file. hp2ps -c foo.hp (for colour) makes it easier to read for me. > You might also check the GHC manual to see whether you manage to work > out what the -hr option does. If you do, please explain it to me. Have you seen the hints subsection of: http://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html#retainer-prof Basically, once you've worked out what is eating space that you think shouldn't you can use retainer profiling, restricted to that sort of thing, to see what is holding on to it, e.g. the example there "-hr -hcB" will show you what is retaining things in cost centre B. You can similarly restrict on most other profile types, e.g. -hr -hyInt to see what is retaining Ints. FWIW I don't remember -hr being particularly useful for darcs debugging in the past. One thing that does tend to make profiling easier is to try deleting code that you hope is not at fault and see if you are still seeing the problem, e.g. for record you might try bypassing the change selection code, deleting the "run the testsuite" code etc. Biographical profiling can also be useful, as you often find the memory you are chasing is drag, lag or void. Thanks Ian _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
