[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Smudged Index Update Performance

Oh. my analysis was wrong it seems. the updating is called only once (i wondered about that already, i just missed the invocation count number in the profiler). but the treewalk with the path filter eats up most of the time. it seems that TreeWalk.isPathPrefix is called /really/ often (~840.000.000 times). i attached a call tree FYI this time, so you can see on your own.

Regards,
Markus

On 07/05/2012 11:31 AM, Markus Duft wrote:
> Ah, i didn't fill out the numbers... sorry;
> 
> The updating takes 435 of 457 seconds. thats ~95% of the whole runtime.
> 
> Regards,
> Markus
> 
> On 07/05/2012 11:29 AM, Markus Duft wrote:
>> Hey!
>>
>> I noticed that since i last updated our JGit tree, all merge operations (merge, rebase, cherry-pick) are quite slow on our big repository. I asked the profiler (JProfiler) for his opinion, and he told me that DirCache.updateSmudgedEntries() eats up ??? seconds of the ??? seconds the cherry-pick took in whole (ofc it's slower because of the profiler, but the relation should be ok...). thats a whopping ?? percent!
>>
>> Any suggestions? AFAICT the problem is that each BaseDirCacheEditor.commit() call will cause a write() on the cache, causing the updating to happen. It now depends (really?) on the number of merged files how often /all/ index entries are checked for smudging. Not so cool. I will have a look into making the update an explicit call that happens further up the call tree only once after finishing the merge, or something like that.
>>
>> Regards,
>> Markus
>> _______________________________________________
>> jgit-dev mailing list
>> jgit-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jgit-dev
>>
> 
> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jgit-dev
> 

Attachment: calltree.tgz
Description: application/compressed-tar