• L
    Make git_dir a path relative to work_tree in setup_work_tree() · 044bbbcb
    Linus Torvalds 提交于
    Once we find the absolute paths for git_dir and work_tree, we can make
    git_dir a relative path since we know pwd will be work_tree. This should
    save the kernel some time traversing the path to work_tree all the time
    if git_dir is inside work_tree.
    
    Daniel's patch didn't apply for me as-is, so I recreated it with some
    differences, and here are the numbers from ten runs each.
    
    There is some IO for me - probably due to more-or-less random flushing of
    the journal - so the variation is bigger than I'd like, but whatever:
    
    	Before:
    		real    0m8.135s
    		real    0m7.933s
    		real    0m8.080s
    		real    0m7.954s
    		real    0m7.949s
    		real    0m8.112s
    		real    0m7.934s
    		real    0m8.059s
    		real    0m7.979s
    		real    0m8.038s
    
    	After:
    		real    0m7.685s
    		real    0m7.968s
    		real    0m7.703s
    		real    0m7.850s
    		real    0m7.995s
    		real    0m7.817s
    		real    0m7.963s
    		real    0m7.955s
    		real    0m7.848s
    		real    0m7.969s
    
    Now, going by "best of ten" (on the assumption that the longer numbers
    are all due to IO), I'm saying a 7.933s -> 7.685s reduction, and it does
    seem to be outside of the noise (ie the "after" case never broke 8s, while
    the "before" case did so half the time).
    
    So looks like about 3% to me.
    
    Doing it for a slightly smaller test-case (just the "arch" subdirectory)
    gets more stable numbers probably due to not filling the journal with
    metadata updates, so we have:
    
    	Before:
    		real    0m1.633s
    		real    0m1.633s
    		real    0m1.633s
    		real    0m1.632s
    		real    0m1.632s
    		real    0m1.630s
    		real    0m1.634s
    		real    0m1.631s
    		real    0m1.632s
    		real    0m1.632s
    
    	After:
    		real    0m1.610s
    		real    0m1.609s
    		real    0m1.610s
    		real    0m1.608s
    		real    0m1.607s
    		real    0m1.610s
    		real    0m1.609s
    		real    0m1.611s
    		real    0m1.608s
    		real    0m1.611s
    
    where I'ld just take the averages and say 1.632 vs 1.610, which is just
    over 1% peformance improvement.
    
    So it's not in the noise, but it's not as big as I initially thought and
    measured.
    
    (That said, it obviously depends on how deep the working directory path is
    too, and whether it is behind NFS or something else that might need to
    cause more work to look up).
    Signed-off-by: NJunio C Hamano <gitster@pobox.com>
    044bbbcb
cache.h 28.4 KB