Web lists-archives.com

Re: Make the git codebase thread-safe


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

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)

Matheus Tavares