It seems like for performance reasons, git-stats wants to update the calendar on commit instead of generating it on the fly. git-cal[0] just does this on the fly and works reasonably fast for me. The UI looks very comparable.

[0] https://github.com/k4rthik/git-cal

Hmm, just installed git-cal and it certainly is adequately fast on my main work repo. But it seems to just be for the current branch? (That seems sensible enough, but also makes it somewhat less useful.)

Added an option to view stats from all branches ( git-cal --all ), but that'll be slower for large repositories

Brill, it's still quite fast on my work repo, and much more useful to me. :)

Looks like that he parses the log with the hook and then stores the json output in ~/.git-stats (git-stats --record), my guess is that he then generates the calendar only from that data so that he doesn't have to parse the whole history all over again. I'm a bit worried about the size of that file though...

If you were fully awake you'd notice it also talks about executing a remote file that you have no control over on every git commit you run.