On Wed, Apr 20, 2016 at 7:28 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> 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.

Just to be clear, these are unoptimized numbers, no untracked cache,
no split index, no index helper, and on a tiny repository that is
git.git. It's mostly to show the percentage of time spent in each
phase. We probably can do similar measurement and record it in the
watchman patch (can't wait for lmdb to be here :).
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to