On Sat, Jan 27, 2018 at 7:28 AM, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > 3) A lot of time spend reading the index (or something..) I'm resending a patch from my old index-helper series. It should measure all big time consuming blocks in git. Maybe we should get it merged... > While the hook itself takes ~20ms (and watchman itself 1/4 of that) > status as a whole takes much longer. gprof reveals: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 15.38 0.02 0.02 221690 0.00 0.00 memihash This sounds like name-hash to me. > 15.38 0.04 0.02 221689 0.00 0.00 create_from_disk > 7.69 0.05 0.01 2216897 0.00 0.00 git_bswap32 > 7.69 0.06 0.01 222661 0.00 0.00 ce_path_match > 7.69 0.07 0.01 221769 0.00 0.00 hashmap_add > 7.69 0.08 0.01 39941 0.00 0.00 prep_exclude > 7.69 0.09 0.01 39940 0.00 0.00 strbuf_addch > 7.69 0.10 0.01 1 10.00 10.00 read_one > 7.69 0.11 0.01 1 10.00 10.00 refresh_index > 7.69 0.12 0.01 1 10.00 10.00 tweak_fsmonitor > 7.69 0.13 0.01 preload_thread > > The index is 24M in this case, I guess it's unpacking it, but I wonder > if this couldn't be much faster if we saved away the result of the last > "status" in something that's quick to access, and then if nothing No we could do better, we could cache parsed index content so everybody benefits. I demonstrated it with my "index v254" patch a while back: https://public-inbox.org/git/1399980019-8706-1-git-send-email-pclouds@xxxxxxxxx/ With the patch I'm sending soon, we can see how much time reading an index take out of that ~140-150ms (and we probably can cut down index read time to like 10-20% when cached). > changed we just report that, and no need to re-write the index (or just > write the "it was clean at this time" part). Hmm.. does an index write increase that much time? -- Duy
