On Mon, 2014-05-12 at 17:45 +0700, Duy Nguyen wrote: > This is your quote from above, moved down a bit: > > > update_fs_cache should only have to update based on what it has learned > > from watchman. So if no .gitignore has been changed, it should not have > > to do very much work. > > > > I could take the fe_excluded check and move it above the > > last_exclude_matching check in fs_cache_is_excluded; it causes t7300 to > > fail when run under watchman but presumably that's fixable > > So you exclude files early and make the real read_directory() pass do > pretty much nothing. This is probably not a good idea. Assume that I > touch $TOP/.gitignore then do something other than "git status" (or > "git add") then I have to pay read_directory() cost. I'm not sure I understand this. read_directory does something: it checks the fs_cache (instead of the filesystem) for untracked files. > Back to the open vs fs_cache_open and the number of .gitignore files > above. I touch $TOP/.gitignore then do "git status" to make it read > all .gitignore files (6k of them) and change between open and > fs_cache_open. I think the numbers still do not make any visible > difference (~1620-1630ms). Yes, I would expect no win in that case. fs_cache_open will only save time in the common case where there is no .gitignore file, because it saves an open() call. If every possible .gitignore file exists, of course it makes no difference. But also, your processor may be sufficiently slow that the context-switch penalty for open() is less than the hash table lookup. For me, the win from fs_cache_open is about 7%. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html