From: "René Scharfe" <l.s.r@web.de>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Brandon Williams <bmwill@google.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH] dir: avoid allocation in fill_directory()
Date: Fri, 10 Feb 2017 20:42:22 +0100 [thread overview]
Message-ID: <213ef44b-9161-1e64-772c-76d93619b6f6@web.de> (raw)
In-Reply-To: <CACsJy8CE-cyTZHZZhvhdsNau7iSqBci1BdUqDYvxoE5odV2SBA@mail.gmail.com>
Am 08.02.2017 um 07:22 schrieb Duy Nguyen:
> On Wed, Feb 8, 2017 at 5:04 AM, René Scharfe <l.s.r@web.de> wrote:
>> Pass the match member of the first pathspec item directly to
>> read_directory() instead of using common_prefix() to duplicate it first,
>> thus avoiding memory duplication, strlen(3) and free(3).
>
> How about killing common_prefix()? There are two other callers in
> ls-files.c and commit.c and it looks safe to do (but I didn't look
> very hard).
I would like that, but it doesn't look like it's worth it. I have a
patch series for making overlay_tree_on_cache() take pointer+length, but
it's surprisingly long and bloats the code. Duplicating a small piece
of memory once per command doesn't look so bad in comparison.
(The payoff for avoiding an allocation is higher for library functions
like fill_directory().)
But while working on that I found two opportunities for improvement in
prune_cache(). I'll send patches shortly.
> There's a subtle difference. Before the patch, prefix[prefix_len] is
> NUL. After the patch, it's not always true. If some code (incorrectly)
> depends on that, this patch exposes it. I had a look inside
> read_directory() though and it looks like no such code exists. So, all
> good.
Thanks for checking.
NB: The code before 966de302 (dir: convert fill_directory to use the
pathspec struct interface, committed 2017-01-04) made the same
assumption, i.e. that NUL is not needed.
René
prev parent reply other threads:[~2017-02-10 19:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 22:04 [PATCH] dir: avoid allocation in fill_directory() René Scharfe
2017-02-08 6:22 ` Duy Nguyen
2017-02-08 19:54 ` Brandon Williams
2017-02-10 19:42 ` René Scharfe [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=213ef44b-9161-1e64-772c-76d93619b6f6@web.de \
--to=l.s.r@web.de \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).