public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v5 08/11] libio: Convert __vasprintf_internal to buffers
Date: Fri, 16 Dec 2022 19:22:19 +0100	[thread overview]
Message-ID: <87tu1vryxw.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <08779a8a-1dcb-495c-6d1c-5c629141a606@linaro.org> (Adhemerval Zanella Netto's message of "Thu, 15 Dec 2022 15:40:47 -0300")

* Adhemerval Zanella Netto:

> On 12/12/22 12:23, Florian Weimer via Libc-alpha wrote:
>> The buffer resizing algorithm is slightly different.  The initial
>> buffer is on the stack, and small buffers are directly allocated
>> on the heap using the exact required size.  The overhead of the
>> additional copy is compensated by the lowered setup cost for buffers
>> compared to libio streams.
>
> Patch look good, some comments below.

Thanks.

>> +struct __printf_buffer_asprintf
>> +{
>> +  /* base.write_base points either to a heap-allocated buffer, or to
>> +     the direct array below.  */
>> +  struct __printf_buffer base;
>> +
>> +  /* Initial allocation.  200 should be large enough to copy almost
>> +     all asprintf usages with just a single (final, correctly sized)
>> +     heap allocation.  */
>> +  char direct[200];
>> +};
>
> There are couple or more buffer sizes scattered in this patchset, maybe it
> would be better to consolidate them in one place so it can be easily tuned.

I see what I can do.

> For instance, since it is used with memcpy below, maybe it would be better
> to use a size that compiler can inline (it would be arch-dependent, but 
> using a size that most usual architecture inline is a net gain).

It would need additional optimization hints for GCC, I believe.

>> +void
>> +__printf_buffer_flush_asprintf (struct __printf_buffer_asprintf *buf)
>> +{
>> +  size_t current_pos = buf->base.write_ptr - buf->base.write_base;
>> +  if (current_pos >= INT_MAX)
>
> Shouldn't it be SSIZE_MAX?

Nope, asprintf has the same incorrect return type as printf. 8-(

>
>> +    {
>> +      /* The result is not representable.  No need to continue.  */
>> +      __set_errno (EOVERFLOW);
>> +      __printf_buffer_mark_failed (&buf->base);
>> +      return;
>> +    }
>> +
>> +  size_t current_size = buf->base.write_end - buf->base.write_base;
>> +  /* Implement an exponentiatial sizing policy.  Keep the size
>
> s/exponentiatial/exponential

Fixed.

>> +     congruent 8 (mod 16), to account for the footer in glibc
>> +     malloc.  */
>> +  size_t new_size = ((current_size + current_size / 2) & -15) | 8;
>
> Maybe use ALIGN_UP ((current_size + current_size / 2), 16) here?

Changed.

Thanks,
Florian


  reply	other threads:[~2022-12-16 18:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 15:22 [PATCH v5 00/11] vfprintf refactor Florian Weimer
2022-12-12 15:22 ` [PATCH v5 01/11] locale: Implement struct grouping_iterator Florian Weimer
2022-12-12 15:22 ` [PATCH v5 02/11] stdio-common: Introduce buffers for implementing printf Florian Weimer
2022-12-14 14:10   ` Adhemerval Zanella Netto
2022-12-16 17:51     ` Florian Weimer
2022-12-12 15:23 ` [PATCH v5 03/11] stdio-common: Add __printf_function_invoke Florian Weimer
2022-12-14 14:28   ` Adhemerval Zanella Netto
2022-12-12 15:23 ` [PATCH v5 04/11] stdio-common: Add __translated_number_width Florian Weimer
2022-12-14 14:38   ` Adhemerval Zanella Netto
2022-12-12 15:23 ` [PATCH v5 05/11] stdio-common: Convert vfprintf and related functions to buffers Florian Weimer
2022-12-14 20:54   ` Adhemerval Zanella Netto
2022-12-16 17:58     ` Florian Weimer
2022-12-12 15:23 ` [PATCH v5 06/11] stdio-common: Add lock optimization to vfprintf and vfwprintf Florian Weimer
2022-12-15 15:58   ` Adhemerval Zanella Netto
2022-12-12 15:23 ` [PATCH v5 07/11] libio: Convert __vsprintf_internal to buffers Florian Weimer
2022-12-15 18:16   ` Adhemerval Zanella Netto
2022-12-16 18:07     ` Florian Weimer
2022-12-12 15:23 ` [PATCH v5 08/11] libio: Convert __vasprintf_internal " Florian Weimer
2022-12-15 18:40   ` Adhemerval Zanella Netto
2022-12-16 18:22     ` Florian Weimer [this message]
2022-12-12 15:23 ` [PATCH v5 09/11] libio: Convert __vdprintf_internal " Florian Weimer
2022-12-15 19:11   ` Adhemerval Zanella Netto
2022-12-12 15:24 ` [PATCH v5 10/11] libio: Convert __obstack_vprintf_internal to buffers (bug 27124) Florian Weimer
2022-12-15 19:14   ` Adhemerval Zanella Netto
2022-12-16 18:25     ` Florian Weimer

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tu1vryxw.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /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.
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).