From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Jeff King <peff@peff.net>, Kim Gybels <kgybels@infogroep.be>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v3] packed_ref_cache: don't use mmap() for small files
Date: Wed, 24 Jan 2018 10:05:58 -0800 [thread overview]
Message-ID: <xmqq607rf7y1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <cea5e366-dc95-6f41-6373-f8bbef103561@alum.mit.edu> (Michael Haggerty's message of "Wed, 24 Jan 2018 12:05:01 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> The change to using `read()` rather than `mmap()` for small
> `packed-refs` feels like it should be an improvement, but it occurred to
> me that the performance numbers quoted in ea68b0ce9f8 (hash-object:
> don't use mmap() for small files, 2010-02-21) are not directly
> applicable to the `packed-refs` file. As far as I understand, the file
> mmapped in `index_fd()` is always read in full, whereas the main point
> of mmapping the packed-refs file is to avoid having to read the whole
> file at all in some situations. That being said, a 32 KiB file would
> only be 8 pages (assuming a page size of 4 KiB), and by the time you've
> read the header and binary-searched to find the desired record, you've
> probably paged in most of the file anyway. Reading the whole file at
> once, in order, is almost certainly cheaper.
Yup. So unless your "small" is meaningfully large, we are likely to
be better off with read(2), but I suspect that this might not be
even measuable since we are only talking about "small" files.
prev parent reply other threads:[~2018-01-24 18:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-13 16:11 [PATCH] packed_ref_cache: don't use mmap() for small files Kim Gybels
2018-01-13 18:56 ` Johannes Schindelin
2018-01-14 19:14 ` [PATCH v2] " Kim Gybels
2018-01-15 12:17 ` [PATCH 0/3] Supplements to "packed_ref_cache: don't use mmap() for small files" Michael Haggerty
2018-01-15 12:17 ` [PATCH 1/3] SQUASH? Mention that `snapshot::buf` can be NULL for empty files Michael Haggerty
2018-01-15 12:17 ` [PATCH 2/3] create_snapshot(): exit early if the file was empty Michael Haggerty
2018-01-15 12:17 ` [PATCH 3/3] find_reference_location(): don't invoke if `snapshot->buf` is NULL Michael Haggerty
2018-01-17 20:23 ` [PATCH 0/3] Supplements to "packed_ref_cache: don't use mmap() for small files" Johannes Schindelin
2018-01-17 21:52 ` Junio C Hamano
2018-01-15 21:15 ` [PATCH] packed_ref_cache: don't use mmap() for small files Jeff King
2018-01-15 23:37 ` Kim Gybels
2018-01-15 23:52 ` Jeff King
2018-01-16 19:38 ` [PATCH v3] " Kim Gybels
2018-01-17 22:09 ` Jeff King
2018-01-21 4:41 ` Michael Haggerty
2018-01-22 19:31 ` Junio C Hamano
2018-01-24 11:05 ` Michael Haggerty
2018-01-24 11:14 ` [PATCH 0/6] Yet another approach to handling empty snapshots Michael Haggerty
2018-01-24 11:14 ` [PATCH 1/6] struct snapshot: store `start` rather than `header_len` Michael Haggerty
2018-01-24 20:36 ` Jeff King
2018-01-24 11:14 ` [PATCH 2/6] create_snapshot(): use `xmemdupz()` rather than a strbuf Michael Haggerty
2018-01-24 11:14 ` [PATCH 3/6] find_reference_location(): make function safe for empty snapshots Michael Haggerty
2018-01-24 20:27 ` Jeff King
2018-01-24 21:11 ` Junio C Hamano
2018-01-24 21:34 ` Jeff King
2018-01-24 11:14 ` [PATCH 4/6] packed_ref_iterator_begin(): make optimization more general Michael Haggerty
2018-01-24 20:32 ` Jeff King
2018-01-24 11:14 ` [PATCH 5/6] load_contents(): don't try to mmap an empty file Michael Haggerty
2018-01-24 11:14 ` [PATCH 6/6] packed_ref_cache: don't use mmap() for small files Michael Haggerty
2018-01-24 20:38 ` [PATCH 0/6] Yet another approach to handling empty snapshots Jeff King
2018-01-24 20:54 ` Junio C Hamano
2018-02-15 16:54 ` Johannes Schindelin
2018-01-24 18:05 ` Junio C Hamano [this message]
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=xmqq607rf7y1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=kgybels@infogroep.be \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/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.