On 1/6/20 5:08 PM, Tim Rühsen wrote:
>>   * What about reusing the complete vasnprintf.c for (B), rather than
>>     adding another, limited printf-like implementation?
> 
> Yes, would be nice. At least for appending we need an extra
> malloc/malloc/memcpy/free.
> 
> vasnprintf reallocates RESULTBUF that means we can't use a stack
> allocated buffer - thus we lose the performance advantage. Or should we
> try snprintf first and fallback to vasnprintf in case of truncation ?
> 
> We want another module e.g. buffer-printf to not pull in vasnprintf when
> not needing printf-like buffer functions.
> 
> Once the buffer module is done, we could think of amending vasnprintf to
> better play with the buffer type.

Just made a speed comparison between vasnprintf and wget_buffer_printf,
10m times executed, within a stack-only szenario (no reallocations), gcc
9.2.1, -O1 -g.

asnprintf(sbuf, &size, "%d", i);
takes 0m2.727s

wget_buffer_printf(&buf, "%d", i);
takes 0m0.226s

char s[]="123";

asnprintf(sbuf, &size, "%s", s);
takes 0m2.282s

wget_buffer_printf(&buf, "%s", s);
takes 0m0.212s

It tells me that vasnprintf has a huge startup overhead. Perhaps we can
tweak that a little bit.


the vasnprintf program that I run for %d:

#include <vasnprintf.h>

void main(void)
{
  char sbuf[256];
  size_t size = sizeof(sbuf);

  for (int i=0;i<1000000;i++) {
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
    asnprintf(sbuf, &size, "%d", i);
  }
}