On Thu, May 22, 2008 at 5:07 AM, Reinier Lamers <[EMAIL PROTECTED]> wrote: >> Did you actually test that this affects the memory use of put? It'd >> greatly >> surprise me if it affected our memory use by more than a couple of >> percent, >> and for such a small gain, I'm not convinced it's worth the >> complexity. Of >> course, it could also either improve or hurt the cpu time used in >> put and >> apply, and I'd be interested in knowing which effect it has. > > Your scepticism is entirely justified: when I tested a darcs with my > patch against darcs 2.0.0 on OS X, the version with my patch used a > similar amount of memory (300 to 340 MB), but took much more CPU time > (1m 38s user (average of two runs) versus 24.5s (average of four > runs)). So my perceived great results were either because I compiled - > fvia-C (to avoid http://hackage.haskell.org/trac/ghc/ticket/1993), > because I had enabled profiling, or because the memory behavior is > wildly different on Linux and OS X, or because I did something > completely braindead. I'm going to try and find out which one was the > cause.
I've just reproduced the same result again on a 32 bit machine (both linux machines running debian and ghc 6.6), only the fractional time penalty is smaller. I figured out an interesting trick for seeing memory use: top -b -d 1 -c | grep darcs > track-memory saves every second the memory use of any running darcs commands, along with the command line. From this, I've learned that when doing a local darcs put (which is most certainly not the situation we want to optimize for, as a local darcs get is always going to be more efficient... unless we make put call get, which would make memory measurements of the "real" put trickier) most of the memory is used by apply, not by put (well, two-thirds of it). One bug is that put never releases its memory until the apply completes. It should be able to free memory as it's being written in pipeDoc, and I'm not sure why it doesn't. It's possible that appy is also inefficient. It's memory use has a big spike that seems suspicious. David _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
