All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Zager <szager@chromium.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Zager <szager@chromium.org>,
	Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Make the git codebase thread-safe
Date: Wed, 12 Feb 2014 12:27:50 -0800	[thread overview]
Message-ID: <CAHOQ7J8Q1905pVwx9QVib1BM-Xxg8vTL=hDUjT7garX++VXm3g@mail.gmail.com> (raw)
In-Reply-To: <xmqqr478m6xx.fsf@gitster.dls.corp.google.com>

On Wed, Feb 12, 2014 at 12:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Zager <szager@chromium.org> writes:
>
>> ...  I used the Very Sleepy profiler
>> to see where all the time was spent on Windows: 55% of the time was
>> spent in OpenFile, and 25% in CloseFile (both in win32).
>
> This is somewhat interesting.
>
> When we check things out, checkout_paths() has a list of paths to be
> checked out, and iterates over them and call checkout_entry().
>
> I wonder if you can:
>
>  - introduce a version of checkout_entry() that takes file
>    descriptors to write to;
>
>  - have an asynchronous helper threads that pre-open the paths to be
>    written out and feed <ce, file descriptor to be written> to a
>    queue;
>
>  - restructure that loop so that it reads the <ce, file descriptor
>    to be written> from the queue, performs the actual writing out,
>    and then feeds <file descriptor to be closed> to another queue; and
>
>  - have another asynchronous helper threads that reads <file
>    descriptor to be closed> from the queue and close them.
>
> Calls to write (and preparation of data to be written) will then
> remain single-threaded, but it sounds like that codepath is not the
> bottleneck in your measurement, so....

Yes, I considered that as well.  At a minimum, that would still
require attr.c to implement thread locking, since attribute files must
be parsed to look for stream filters.  I have already done that work.

But I'm not sure it's the best long-term approach to add convoluted
custom threading solutions to each git operation as it appears on the
performance radar.  I'm hoping to make the entire code base more
thread-friendly, so that threading can be added in a more natural and
idiomatic (and less painful) way.

For example, the most natural way to add threading to checkout would
be in the loops over the index in check_updates() in unpack-trees.c.
If attr.c and sha1_file.c were thread-safe, then it would be possible
to thread checkout entirely in check_updates(), with a pretty compact
code change.  I have already done the work in attr.c; sha1_file.c is
hairier, but do-able.

Stefan

  reply	other threads:[~2014-02-12 20:27 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12  1:54 Make the git codebase thread-safe Stefan Zager
2014-02-12  2:02 ` Robin H. Johnson
2014-02-12  3:43   ` Duy Nguyen
2014-02-12 11:00     ` Karsten Blees
2014-02-12 23:03       ` Mike Hommey
2014-02-13  0:06         ` Karsten Blees
2014-02-12 18:15     ` Stefan Zager
2014-02-12  2:11 ` Duy Nguyen
2014-02-12 18:12   ` Stefan Zager
2014-02-12 18:33     ` Matthieu Moy
2014-02-12 18:39       ` Stefan Zager
2014-02-12 18:50     ` David Kastrup
2014-02-12 19:02       ` Stefan Zager
2014-02-12 19:15         ` David Kastrup
2014-02-12 23:09           ` Mike Hommey
2014-02-13  6:04             ` David Kastrup
2014-02-13  9:34               ` Mike Hommey
2014-02-13  9:48                 ` Mike Hommey
2014-02-13  8:30           ` David Kastrup
2014-02-12 20:06     ` Junio C Hamano
2014-02-12 20:27       ` Stefan Zager [this message]
2014-02-12 23:05         ` Junio C Hamano
2014-02-12 11:59 ` Erik Faye-Lund
2014-02-12 18:20   ` Stefan Zager
2014-02-12 18:27     ` Erik Faye-Lund
2014-02-12 18:34       ` Stefan Zager
2014-02-12 18:37         ` Erik Faye-Lund
2014-02-12 19:22           ` Karsten Blees
2014-02-12 19:30             ` Stefan Zager
2014-02-13  8:27               ` Johannes Sixt
2014-02-13  8:38                 ` David Kastrup
2014-02-13 18:40                 ` Stefan Zager
2014-02-13 18:38             ` Zachary Turner
2014-02-13 22:51               ` Karsten Blees
2014-02-13 22:53                 ` Stefan Zager
2014-02-13 23:09                   ` Zachary Turner
2014-02-14 19:04                     ` Karsten Blees
     [not found]                       ` <CAAErz9g7ND1htfk=yxRJJLbSEgBi4EV_AHC9uDRptugGWFWcXw@mail.gmail.com>
2014-02-14 19:16                         ` Zachary Turner
2014-02-14 23:10                           ` Karsten Blees
2014-02-15  0:45                           ` Duy Nguyen
2014-02-15  0:50                             ` Stefan Zager
2014-02-15  0:56                               ` Duy Nguyen
2014-02-15  1:15                                 ` Zachary Turner
2014-02-15  1:39                                   ` Duy Nguyen
2014-02-18 17:55                                     ` Junio C Hamano
2014-02-18 18:14                                       ` Zachary Turner
2014-02-14 19:52                         ` Stefan Zager
2014-02-14 21:49                       ` Stefan Zager
2014-02-13  1:42 ` brian m. carlson
2019-04-02  0:52 ` Matheus Tavares
2019-04-02  1:07   ` Duy Nguyen
2019-04-02 10:30     ` David Kastrup
2019-04-02 11:35       ` Duy Nguyen
2019-04-02 11:52         ` David Kastrup
2019-04-02 19:06     ` Matheus Tavares Bernardino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHOQ7J8Q1905pVwx9QVib1BM-Xxg8vTL=hDUjT7garX++VXm3g@mail.gmail.com' \
    --to=szager@chromium.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.