On Thu, 29 Mar 2012 17:11:36 -0400, Jeff King <peff@xxxxxxxx> wrote: > So we were sitting around chatting today about how slow "git status" is > in the gigantic WebKit repository (because really, what else would one > chat about?). Carlos noticed that git spends a lot of time in the > gitignore code path. It turns out that the WebKit repository has a > couple hundred excludes in the top-level .gitignore, many of which are > for specific files deep in the repository. > > Since these patterns are compared via fnmatch(), we have to process them > linearly for each entry[1]. And since the patterns are at the top level, > we check them for each of the ~180,000 files in the repository. So "git > status" will do O(m*n) work, where "m" is the number of patterns and "n" > is the number of files in the repository. And as a project grows over > time, one might expect "m" to be some constant factor of "n". So this is > really O(n^2) (albeit with some mitigating constant at the front). Many months ago I noticed that as well, when somebody came to #git and complained that git status is slow (it toook *many* seconds for him). We tracked that down to the fact that his .gitignore contained hundreds of entries. He basically did `git ls-files --other >> .gitignore`, so his .gitignore included every single object file and all other build artefacts. I told him to use wildcards and `git status` became usable again. tom -- 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