From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Tue, 12 Jul 2011 05:43:58 GMT
Subject: Re: [PATCH 11/17] revert: Save data for continuing after conflict resolution
Message-ID: <CALkWK0=W58pHShDeoPkys2gYNAk+VSP7CCVijvSDq6N_NdLaKw@mail.gmail.com>
In-Reply-To: <7vbox0cz1j.fsf@alter.siamese.dyndns.org>

Hi Junio,

Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> + *
>> + * Usage example:
>> + *
>> + *     struct commit_list *list;
>> + *     struct commit_list **next = &list;
>> + *
>> + *     next = commit_list_append(c1, next);
>> + *     next = commit_list_append(c2, next);
>> + *     *next = NULL;
>> + *     assert(commit_list_count(list) == 2);
>> + *     return list;
>> + *
>> + * Don't forget to NULL-terminate!
>
> I am still not convinced that making it the caller's responsibility to
> NULL-terminate the list after it finishes to append is a good trade-off
> between run-time performance and ease of API use.  If you are appending
> thousands of commits to a commit list in a tight loop, surely you would
> save the same thousands of assignment of NULL to the next field of the
> element at the tail of the list, which may reduce the instruction count a
> tiny bit, but that field was assigned in the last round in that tight loop
> and the cacheline would likely to be owned by the CPU already, so it might
> not make much practical difference.

Ah, I hadn't thought about it this deeply.  Changed now- thanks for
the explanation.

-- Ram