From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Brandon Williams <bmwill@google.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] oidmap: ensure map is initialized
Date: Sat, 23 Dec 2017 01:23:53 +0100 (STD) [thread overview]
Message-ID: <alpine.DEB.2.21.1.1712230118340.406@MININT-6BKU6QN.europe.corp.microsoft.com> (raw)
In-Reply-To: <20171222232729.253936-1-bmwill@google.com>
Hi Brandon,
On Fri, 22 Dec 2017, Brandon Williams wrote:
> Ensure that an oidmap is initialized before attempting to add, remove,
> or retrieve an entry by simply performing the initialization step
> before accessing the underlying hashmap.
>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> oidmap.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/oidmap.c b/oidmap.c
> index 6db4fffcd..d9fb19ba6 100644
> --- a/oidmap.c
> +++ b/oidmap.c
> @@ -33,12 +33,19 @@ void oidmap_free(struct oidmap *map, int free_entries)
>
> void *oidmap_get(const struct oidmap *map, const struct object_id *key)
> {
> + if (!map->map.cmpfn)
> + return NULL;
> +
This one is unnecessary: if we always _init() before we add, then
hashmap_get_from_hash() will not have anything to compare, and therefore
not call cmpfn.
You could argue that it is only a teeny-tiny runtime cost, so it'd be
better to be safe than to be sorry.
However, it is a death by a thousand cuts. My colleagues and I try to
shave off a few percent here and a few percent there, in the hope to get
some performance improvements worth writing home about. And then patches
like this one come in that simply add runtime without much in the way of
performance considerations.
And that makes me quite a bit sad.
> return hashmap_get_from_hash(&map->map, hash(key), key);
> }
>
> void *oidmap_remove(struct oidmap *map, const struct object_id *key)
> {
> struct hashmap_entry entry;
> +
> + if (!map->map.cmpfn)
> + oidmap_init(map, 0);
> +
> hashmap_entry_init(&entry, hash(key));
> return hashmap_remove(&map->map, &entry, key);
> }
> @@ -46,6 +53,10 @@ void *oidmap_remove(struct oidmap *map, const struct object_id *key)
> void *oidmap_put(struct oidmap *map, void *entry)
> {
> struct oidmap_entry *to_put = entry;
> +
> + if (!map->map.cmpfn)
> + oidmap_init(map, 0);
> +
> hashmap_entry_init(&to_put->internal_entry, hash(&to_put->oid));
> return hashmap_put(&map->map, to_put);
> }
"But it does not add a lot, it's only a couple of microseconds"
Sure. But we could (and do) simply initialize the hashmaps once, and avoid
having to spend unnecessary cycles for every single access.
I *much* prefer my original patch that essentially does not change *any*
code path. Everything stays the same, except that there is now a strong
hint explaining why you need to call oidmap_init() manually instead of
using the OIDMAP_INIT macro and then wonder why your code crashes.
Ciao,
Dscho
next prev parent reply other threads:[~2017-12-23 0:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 10:59 [PATCH] oidmap.h: strongly discourage using OIDMAP_INIT directly Johannes Schindelin
2017-12-22 17:16 ` Brandon Williams
2017-12-22 20:12 ` Junio C Hamano
2017-12-22 23:27 ` [PATCH] oidmap: ensure map is initialized Brandon Williams
2017-12-23 0:23 ` Johannes Schindelin [this message]
2017-12-27 18:01 ` Junio C Hamano
2017-12-23 0:15 ` [PATCH] oidmap.h: strongly discourage using OIDMAP_INIT directly Johannes Schindelin
2018-01-02 18:13 ` Jeff Hostetler
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=alpine.DEB.2.21.1.1712230118340.406@MININT-6BKU6QN.europe.corp.microsoft.com \
--to=johannes.schindelin@gmx.de \
--cc=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).