Hello Jason, Monday, January 23, 2006, 9:38:02 AM, you wrote: JD> Potentially useful information about darcs; JD> 1) Uses a slightly modified version of FastPackedStrings. what you mean? afaik, there is no standard FastPackedString implementation, but there is some library that with minimal modifications used in darcs, jhc and many other apps JD> still reports large amounts of memory used. Does ghc use mmap to JD> allocate memory instead of malloc? afaik, the answer is yes. look at ghc-6.4.1-src\ghc\rts\MBlock.c JD> I'm looking for advice or help in optimizing darcs in this case. I JD> guess this could be viewed as a challenge for people that felt like JD> the micro benchmarks of the shootout were unfair to Haskell. Can we JD> demonstrate that Haskell provides good performance in the real-world JD> when working with large files? Ideally, darcs could easily work with JD> a patch that is 10GB in size using only a few megs of ram if need be JD> and doing so in about the time it takes read the file once or twice JD> and gzip it. it seems that Ian just used this as memory/time-efficient alternative for hGetContents. reading from memory-mapped file may be done as pure computation if the whole file is mapped. is this used in darcs? if not, then we can map small block at the time or even just use hGetBuf - at least, for first version. what you will say about this? JD> Just to recap, I'm looking for 1) advice, 2) tips, 3) design ideas, JD> 4) tools, 5) libraries and just about anything else :) i'll be happy to help, but i'm not ready to study the darcs code. i'm ready to solve more concrete problems - such as providing new input mechanism with given external interface or optimizing something rather small -- Best regards, Bulat mailto:bulatz@HotPOP.com