On 26 August 2014 02:44, Junio C Hamano <[email protected]> wrote:
> Arjun Sreedharan <[email protected]> writes:
>
>> Find and allocate the required amount instead of allocating extra
>> 100 bytes
>>
>> Signed-off-by: Arjun Sreedharan <[email protected]>
>> ---
>
> Interesting. How much memory do we typically waste (in other words,
> how big did "cnt" grew in your repository where you noticed this)?
>
I did not try to make an observation of that. I was thinking we're
anyway better off
not using a magic number to allot memory on the heap for each item in
the commit list.
>> bisect.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/bisect.c b/bisect.c
>> index d6e851d..c96aab0 100644
>> --- a/bisect.c
>> +++ b/bisect.c
>> @@ -215,10 +215,13 @@ static struct commit_list
>> *best_bisection_sorted(struct commit_list *list, int n
>> }
>> qsort(array, cnt, sizeof(*array), compare_commit_dist);
>> for (p = list, i = 0; i < cnt; i++) {
>> - struct name_decoration *r = xmalloc(sizeof(*r) + 100);
>> + char name[100];
>> + sprintf(name, "dist=%d", array[i].distance);
>> + int name_len = strlen(name);
>
> Decl-after-stmt.
>
> You do not have to run a separate strlen() for this. The return
> value from sprintf() should tell you how much you need to allocate,
> I think.
>
Yes. yes.
>> + struct name_decoration *r = xmalloc(sizeof(*r) + name_len);
>> struct object *obj = &(array[i].commit->object);
>>
>> - sprintf(r->name, "dist=%d", array[i].distance);
>> + memcpy(r->name, name, name_len + 1);
>> r->next = add_decoration(&name_decoration, obj, r);
>> p->item = array[i].commit;
>> p = p->next;
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
