Re: Make the git codebase thread-safe

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

 



Stefan Zager <szager@xxxxxxxxxxxx> writes:

> On Tue, Feb 11, 2014 at 6:11 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>>
>> I have no comments about thread safety improvements (well, not yet).
>> If you have investigated about git performance on chromium
>> repositories, could you please sum it up? Threading may be an option
>> to improve performance, but it's probably not the only option.
>
> Well, the painful operations that we use frequently are pack-objects,
> checkout, status, and blame.

Have you checked the patch in
<URL:http://thread.gmane.org/gmane.comp.version-control.git/241448> and
followups,
Message-ID: <1391454849-26558-1-git-send-email-dak@xxxxxxx>?

While this does not yet support -M and -C options, it's conceivable that
you don't use them in your server/scripts.

> Anything on Windows that touches a lot of files is miserable due to
> the usual file system slowness on Windows, and luafv.sys (the UAC file
> virtualization driver) seems to make it much worse.

There is an obvious solution here...  Dedicated hardware is not that
expensive.  Virtualization will always have a price.

> Blame is something that chromium and blink developers use heavily, and
> it is not unusual for a blame invocation on the blink repository to
> run for 30 seconds.  It seems like it should be possible to
> parallelize blame, but it requires pack file operations to be
> thread-safe.

Really, give the above patch a try.  I am taking longer to finish it
than anticipated (with a lot due to procrastination but that is,
unfortunately, a large part of my workflow), and it's cutting into my
"paychecks" (voluntary donations which to a good degree depend on timely
and nontrivial progress reports for my freely available work on GNU
LilyPond).

Note that it looks like the majority of the remaining time on GNU/Linux
tends to be spent in system time: I/O time, memory management.  And I
have an SSD drive.  When using packed repositories of considerable size,
decompression comes into play as well.  I don't think that you can hope
to get noticeably higher I/O throughput by multithreading, so really,
really, really consider dedicated hardware running on a native Linux
file system.

-- 
David Kastrup
--
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




[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]