Hi Duy, On Wed, 20 Apr 2016, Nguyễn Thái Ngọc Duy wrote: > All the known heavy code blocks are measured (except object database > access). This should help identify if an optimization is effective or > not. An unoptimized git-status would give something like below (92% of > time is accounted). To sum up the effort of making git scale better: > > - read cache line is being addressed by index-helper > - preload/refresh index by watchman > - read packed refs by lmdb backend > - diff-index by rebuilding cache-tree > - read directory by untracked cache and watchman > - write index by split index > - name hash potientially by index-helper > > read-cache.c:2075 performance: 0.004058570 s: read cache .../index > preload-index.c:104 performance: 0.004419864 s: preload index > read-cache.c:1265 performance: 0.000185224 s: refresh index > refs/files-backend.c:1100 performance: 0.001935788 s: read packed refs > diff-lib.c:240 performance: 0.000144132 s: diff-files > diff-lib.c:506 performance: 0.013592000 s: diff-index > name-hash.c:128 performance: 0.000614177 s: initialize name hash > dir.c:2030 performance: 0.015814103 s: read directory > read-cache.c:2565 performance: 0.004052343 s: write index, changed mask = 2 > trace.c:420 performance: 0.048365509 s: git command: './git' 'status' Thank you for doing this! It will be *highly* valuable to get the performance on Windows where I want it to be, too. Ciao, Dscho