René Scharfe wrote:
> Am 02.12.2011 14:07, schrieb Thomas Rast:
> > Measuring grep performance showed that in all but the worktree case
> > (as opposed to --cached,<committish> or<treeish>), threading
> > actually slows things down. For example, on my dual-core
> > hyperthreaded i7 in a linux-2.6.git at v2.6.37-rc2, I got:
> >
> > Threads worktree case | --cached case
> > --------------------------------------------------------------------------
> > 8 (default) | 2.17user 0.15sys 0:02.20real | 0.11user 0.26sys 0:00.11real
> > 4 | 2.06user 0.17sys 0:02.08real | 0.11user 0.26sys 0:00.12real
> > 2 | 2.02user 0.25sys 0:02.08real | 0.15user 0.37sys 0:00.28real
> > NO_PTHREADS | 1.57user 0.05sys 0:01.64real | 0.09user 0.12sys 0:00.22real
>
> Are the columns mixed up?
Indeed, sorry.
In case you were wondering why this table is different from the
numbers given in the cover letter: I noticed at some point that I had
an incomplete checkout (apparently 'git checkout -- .' is really not
the same as 'git reset --hard'... sigh). Then I saw that while the
numbers were different, the conclusion was not, so I forgot to update
it.
> This is a bit radical. I think the underlying issue that
> read_sha1_file() is not thread-safe can be solved eventually and then
> we'd need to readd that code.
I'm also scared of sha1_file.c, especially when it gets down to
packfiles. But perhaps it wouldn't be *too* hard to do it in parallel
iff the object can be read from the loose object store.
> PS: Patches one and three missed a signoff.
Oops, thanks, turns out I had a misconfigured alias ...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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