[Haskell-cafe] Performance Tuning & darcs (a real shootout?)

[Bulat Ziganshin]

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 at HotPOP.com