Re: Make the git codebase thread-safe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

I am planning to work on making pack access thread-safe as my GSoC
project, and after that, parallelize git blame or checkout. Or even use
the thread-safe pack access to improve the already parallel grep or
pack-objects.

With this in mind, I would like to know if the problem discussed in this
thread[1] is still an issue on the repos you folks work with (gentoo,
chromium, etc.). And also, could you please let me know which git
commands did you find to me more problematic in them, nowadays?

I downloaded chromium to give it a try and got (on a machine with i7 and
SSD, running Manjaro Linux):

- 17s on blame for a file with long history[2]
- 2m on blame for a huge file[3]
- 15s on log for both [2] and [3]
- 1s for git status

It seems quite a lot, especially with SSD, IMO.

[1] https://public-inbox.org/git/CA+TurHgyUK5sfCKrK+3xY8AeOg0t66vEvFxX=JiA9wXww7eZXQ@xxxxxxxxxxxxxx/
[2] ./chrome/browser/about_flags.cc (same with ./DEPS)
[3] third_party/sqlite/amalgamation/sqlite3.c (7.5M)

Best,
Matheus Tavares



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux