<p>Sorry for the bad formatting im on phone.</p>
<p>The issue is that if count is large enough, na might not end up as count triggering the assert. We can keep the exponential growth with another fix. I didnt realize that was important here.</p>
<p>Thanks</p>
<p>---<br>
Sent from my phone</p>
<div class="gmail_quote">On Oct 5, 2012 6:38 PM, "Petr Machata" <<a href="mailto:pmachata@redhat.com">pmachata@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="mailto:edgar.iglesias@gmail.com">edgar.iglesias@gmail.com</a> writes:<br>
<br>
>  vect_reserve(struct vect *vec, size_t count)<br>
>  {<br>
>       if (count > vec->allocated) {<br>
> -             size_t na = vec->allocated != 0 ? 2 * vec->allocated : 4;<br>
> +             /* Allocate 4 extra slots for growth.  */<br>
> +             size_t na = count + 4;<br>
>               void *n = realloc(vec->data, na * vec->elt_size);<br>
>               if (n == NULL)<br>
>                       return -1;<br>
<br>
That changes performance characteristics of vect_pushback from O(1) to<br>
O(n).  What problem are you seeing that is fixed by this?<br>
<br>
If we are that memory-tight, perhaps we could have a call like<br>
vect_done, which would allocate a new buffer with exact number of slots,<br>
copy stuff there, and release the old buffer (or keep it around for next<br>
vect_init?).  Or there could be a separate ctor taking slot count as an<br>
argument, which we would use to pre-allocate things like value arrays,<br>
where we have a guess on the number of elements.  It depends on what<br>
problem you are trying to solve.<br>
<br>
Thanks,<br>
PM<br>
</blockquote></div>