On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
> David Turner wrote:
> > On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
> > > dturner@ wrote:
> > > > Test repository 1: Linux
> > > >
> > > > Linux is about 45k files in 3k directories. The average length of a
> > > > filename is about 32 bytes.
> > > >
> > > > Git status timing:
> > > > no watchman: 125ms
> > > > watchman: 90ms
> > >
> > > That's very interesting. Do you get similar improvements when doing
> > > something similar in Merurial (watchman vs . no watchman).
> > I have not tried it. My understanding is that this is why Facebook
> > wrote Watchman and added support for it to Mercurial, so I would assume
> > that the improvements are at least this good.
> Yeah, my bet is that they are actually much better (because Mercurial
> can't be so optimized as Git).
> I'm interested in this number because if watchman in Git is improving it
> by 30%, but in Mercurial it's improving it by 100% (made up number),
> therefore it makes sens that you might want it more if you are using hg,
> but not so much if you are using git.
> Also, if similar repositories with Mercurial+watchman are actually
> faster than Git+watchman, that means that there's room for improvement
> in your implementation. This is not a big issue at this point of the
> process, just something nice to know.
Converting git repos to hg seems to be incredibly slow. (I have not yet
tried doing it with git-remote-hg). But I did find a hg repository for
On this repo, I get:
hg without watchman: 620ms
hg with watchman: 264ms
(compared to 125ms/90ms for git).
The number of syscalls is, perhaps also interesting:
no watchman / with watchman
hg 77773 / 5421
git 59180 / 599
(About 1/3 of hg's syscalls with watchman seem to be loading Python
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html