[darcs-devel] darcs patch: Do not reread freshly written patch when recording.

[Jason Dagit]

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