Jon Smirl writes: > gitk takes about a minute to come up on the Mozilla repo when > everything is in cache. It takes about twice as long when things are > cold. It's enough of delay that I don't use the tool. I've been doing some timing measurements with Jon's repo. The results are interesting. It turns out that a lot of the initial delay is in reading all the references. With ~1600 heads and almost as many tags, readrefs was taking about 30 seconds (on my 2.5GHz quad G5), largely because it was doing two execs for each tag, a git rev-parse and a git cat-file, which was a bit stupid. With that fixed, it's about 5 or 6 seconds from starting gitk to seeing a window with commits listed in it in the hot cache case, even still using --topo-order. Without --topo-order it's about 2-3 seconds to seeing the window with commits listed, but the overall process takes longer (I still need to figure out why). In the cold cache case, it takes about 32 seconds to read all the references, even with the fixed version of readrefs, since that's about how long git ls-remote .git takes. Also, if you do gitk --all (as I often do), then gitk does a git rev-parse, which takes about 20 seconds (but then readrefs only takes 10 seconds since the heads are in cache). 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. Paul. - 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