Paul Mackerras <paulus@xxxxxxxxx> wrote: [snip] > The bottom line is that I can speed up the startup for the hot-cache > case quite a lot. The cold-cache case is going to take about 20-30 > seconds whatever I do unless Linus or Junio can come up with a way to > pack the heads and tags. I could read the refs asynchronously but > there will still be a long delay in git rev-parse if you give > arguments such as --all. I've been thinking about implementing ref storage within a Git tree object. Just store the commit/tag/object IDs in a tree (or graph of trees) with a mode of '0'. Anchor that under '.git/refs-tree'. Any edit of a ref would "lock" .git/refs-tree, create a new tree containing the update, then replace .git/refs-tree. But it would put additional stress on the objects directory by creating a lot of trees which would never get pulled into pack files and thus would need to be pruned away on a regular basis. It also would make parallel updates more difficult on the server side as everyone would need to wait for the lock to .git/refs-tree before they can change any ref; today users only need to wait for the ref they are trying to change. It also doesn't help looking up a ref quickly; although trees are sorted they are variable length entries which forces the application to read the entire tree to find its entry. Given those three downsides I haven't put anything to code yet. -- Shawn. - 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