Re: git-merge-cache / StGIT - gitmergeonefile.py: merging one tree into another rather than two trees into merge base

> On Sat, 2005-09-10 at 20:27 +0200, Blaisorblade wrote:
> 
>>I experienced a (performance) problem with StGit, but I don't know if it's the 
>>culprit or if git-merge-cache is.
> 
> 
> ('s/cache/index/g' below since I still use the old names)
> 
> Maybe both. I did some profiling in StGIT but only for trivial patches
> which did not involved calling gitmergeonefile.py. It was taking around
> 2.5s to push a patch with a changed base (involving merge) on an
> NFS-mounted directory but most of the time, 1.8s, was spent in
> git-read-tree to do the actual merge.
> 
> Someone else (Bcc'ed, not sure he wants his address to be public) did

> some profiling on GIT and his conclusion was that most of the time was
> spend in memmove() called from add_cache_entry() in read-cache.c called
> from read-tree.c.
> 
> 
>>Today I was pushing my patch stack (which was against Linux 2.6.13) on top of 
>>the latest snapshot I have (i.e. upstream will likely have some mega of 
>>patches). And it was *really* slow (say it pushed 8 patches in 5 minutes).
> 
> 
> That's indeed very slow. How may files are modified in each patch? Do
> you run it over NFS? Also for profiling, it is useful to run a 'stg
> status' just to warm up the cache a little bit.