On Jan 16, 2006, at 9:02 AM, Ian Lynagh wrote:
That said, it seems Jason's numbers are including mmapped files, so
it's
not clear exactly what's going on.
Yes the previous numbers did include mmap and I hadn't realized it
was important to exclude mmap'd data. Using Ian's memory profiling
tool I redid the 360MB commit (without profiling it finished in about
30min or so). During the *write* of the patch file the memory usage
seems to be pretty low. But it does spike up to almost 600MB
sometime after the write.
You can find several graphs with description at the following link:
http://www.codersbase.com/index.php/Darcs_performance
It's a wiki page that will update as I learn more so if you're
wondering how things are going you can keep checking. As I write
this I'm waiting for one more graph to finish and then I'll upload it.
Incidentally, I think it would be worth looking at having the changes
selection code working its way down the resultant list writing
things to
a selected or unselected temporary file as appropriate, and then
reading
them back in, rather than using the hacks like pull_only_firsts. This
should make it easier to reason about what's going on, and I think
mean
we won't have to worry about profiling affecting the space behaviour
(i.e. I think making that change would mean we can drop the Record and
SelectChanges auto-all-filtering).
Based on what I'm seeing the graphs I think we can ignore the patch
selection code. But maybe not, I'm using -a to record the patches so
maybe it's getting bypassed and not making a difference for that reason.
Thanks,
Jason
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
