From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: bmwill@google.com, git@vger.kernel.org, j6t@kdbg.org,
jacob.keller@gmail.com
Subject: Re: [PATCHv3] attr: convert to new threadsafe API
Date: Wed, 12 Oct 2016 16:33:31 -0700 [thread overview]
Message-ID: <xmqqfuo116t0.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20161012224109.23410-1-sbeller@google.com> (Stefan Beller's message of "Wed, 12 Oct 2016 15:41:09 -0700")
Stefan Beller <sbeller@google.com> writes:
> @@ -89,15 +114,20 @@ static void setup_check(void)
>
> ------------
> const char *path;
> + struct git_attr_result *result;
>
> setup_check();
> - git_check_attr(path, check);
> + result = git_check_attr(path, check);
This looks stale by a few revisions of the other parts of the patch?
> diff --git a/archive.c b/archive.c
> index 11e3951..15849a8 100644
> --- a/archive.c
> +++ b/archive.c
> @@ -107,10 +107,12 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
> void *context)
> {
> static struct strbuf path = STRBUF_INIT;
> + static struct git_attr_check *check;
> +
> struct archiver_context *c = context;
> struct archiver_args *args = c->args;
> write_archive_entry_fn_t write_entry = c->write_entry;
> - static struct git_attr_check *check;
> + struct git_attr_result result = GIT_ATTR_RESULT_INIT;
> const char *path_without_prefix;
> int err;
>
> @@ -124,12 +126,16 @@ static int write_archive_entry(const unsigned char *sha1, const char *base,
> strbuf_addch(&path, '/');
> path_without_prefix = path.buf + args->baselen;
>
> - if (!check)
> - check = git_attr_check_initl("export-ignore", "export-subst", NULL);
> - if (!git_check_attr(path_without_prefix, check)) {
> - if (ATTR_TRUE(check->check[0].value))
> + git_attr_check_initl(&check, "export-ignore", "export-subst", NULL);
> + git_attr_result_init(&result, check);
> +
> + if (!git_check_attr(path_without_prefix, check, &result)) {
> + if (ATTR_TRUE(result.value[0])) {
> + git_attr_result_clear(&result);
> return 0;
> - args->convert = ATTR_TRUE(check->check[1].value);
> + }
> + args->convert = ATTR_TRUE(result.value[1]);
> + git_attr_result_clear(&result);
> }
This is exactly what I meant by "can we avoid alloc/free of result
in leaf function when we _know_ how many attributes we are
interested in already, which is the majority of the case?".
Starting with a simple but unoptimized internal implementation of
the attr subsystem is one thing (which is good). Exposing an API that
cannot be optimally implemented later without changing the callers
is another (which is bad).
By encapsulating each element into "struct git_attr_result", we can
extend the API without changing the API user [*1*].
But I do not think of a way to allow an efficient implementation
later unless the source of the API user somehow says "this user is
only interested in this many attributes", like having this
struct git_attr_result result[2];
(because this caller only wants "ignore" and "subst") on the API
user's side [*2*]. Without such a clue (like the patch above, that
only says "there is a structure called 'result'"), I do not think of
a way to avoid dynamic allocation on the API implementation side.
All the other callers in the patch (pack-objects, convert, ll-merge,
etc.) seem to share the exact same pattern. Each of the leaf
functions knows a fixed set of attributes it is interested in, the
caller iterates over many paths and makes calls to these leaf
functions, and it is a waste to pay alloc/free overhead for each and
every iteration when we know how many elements result needs to
store.
[Footnote]
*1* Would we need a wrapping struct around the array of results? If
that is the case, we may need something ugly like this on the
API user side:
GIT_ATTR_RESULT_TYPE(2) result = {2,};
with something like the following on the API implementation
side:
#define GIT_ATTR_RESULT_TYPE(n) \
struct { \
int num_slots; \
const char *value[n]; \
}
struct git_attr_result {
int num_slots;
const char *value[FLEX_ARRAY];
};
git_attr_result_init(void *result_, struct git_attr_check *check)
{
struct git_attr_result *result = result_;
assert(result->num_slots, check->num_attrs);
...
}
git_check_attr(const char *path,
struct git_attr_check *check,
void *result_)
{
struct git_attr_result *result = result_;
assert(result->num_slots, check->num_attrs);
for (i = 0; i < check_num_attrs; i++)
result->value[i] = ... found value ...;
}
*2* Or the uglier
GIT_ATTR_RESULT_TYPE(2) result = {2,};
I can see why the "check" side would benefit from a structure
that contains an array, but I do not see why "result" side would
want to, so I am hoping that we won't have to do this uglier
variant and just go with the simple "array of resulting values".
next prev parent reply other threads:[~2016-10-12 23:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 22:41 [PATCHv3] attr: convert to new threadsafe API Stefan Beller
2016-10-12 23:33 ` Junio C Hamano [this message]
2016-10-13 18:42 ` Stefan Beller
2016-10-13 22:08 ` Stefan Beller
2016-10-14 15:37 ` Junio C Hamano
2016-10-18 23:52 ` Stefan Beller
2016-10-19 0:06 ` Junio C Hamano
2016-10-19 0:20 ` Stefan Beller
2016-10-19 0:40 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfuo116t0.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=jacob.keller@gmail.com \
--cc=sbeller@google.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).