[Mesa-dev] [PATCH 01/12] glcpp: Print preprocessor output to string_buffer

Grazvydas Ignotas notasas at gmail.com
Sun Jan 8 14:05:10 UTC 2017


Some spelling suggestions, since you seem to be doing another version
of these patches:

On Sat, Jan 7, 2017 at 9:02 PM, Vladislav Egorov <vegorov180 at gmail.com> wrote:
> glcpp's printing is an obvious low hanging fruit:
>
> 1. It unnecessarily uses formatted printing to print output of
>    preprocessing. To print just one character '+' it first uses
>    vsnprintf("%s", "+") to calculate number of characters in the
>    formatted string (while it's known statically), then resizes
>    buffer increasing it by 1 and then again uses vsnprintf() to
>    actually print the string to the resized buffer.
>
> 2. It linearly grows output string buffer. Each time preprocessor
>    prints anything, it reallocates output buffer increasing it by
>    the exact size of appended string. It's bad for two reasons -
>    a) unnecesary realloc() calls, b) to print formatted string it

unnecessary

<snip>

> diff --git a/src/compiler/glsl/glcpp/pp.c b/src/compiler/glsl/glcpp/pp.c
> index b591279..7fbadf9 100644
> --- a/src/compiler/glsl/glcpp/pp.c
> +++ b/src/compiler/glsl/glcpp/pp.c
> @@ -24,7 +24,135 @@
>  #include <assert.h>
>  #include <string.h>
>  #include <ctype.h>
> +#include <stdio.h>
> +#include <limits.h>
>  #include "glcpp.h"
> +#include "util/bitscan.h"
> +#include "util/u_math.h"
> +
> +/* Overhead of ralloc allocation in bytes. Should be equal to
> + * sizeof(ralloc_header), but ralloc_header is not a part of
> + * the ralloc public API. Assume it's 48. It's a slight
> + * overestimation, but it's enough for practical purposes.
> + */
> +#define RALLOC_OVERHEAD 48
> +
> +bool
> +glcpp_strbuffer_ensure_capacity(glcpp_parser_t *parser,
> +                               struct string_buffer *str, size_t len_append)
> +{
> +       /* Existing string length + 1 null-character + new characters */
> +       size_t min_capacity = str->length + 1 + len_append;
> +       if (unlikely(min_capacity <= str->length))
> +               return false;
> +       if (unlikely(min_capacity > str->capacity)) {
> +               char *new_buf;
> +               size_t new_capacity = str->capacity;
> +               size_t overhead_capacity;;
> +               do {
> +                       /* Grow factor = 1.5. Most of string implementations
> +                        * have grow factor 1.5 (MSVC, Clang, FBVector), with
> +                        * exception of GCC that has grow factor of 2.
> +                        */
> +                       new_capacity = 3 * (new_capacity + 1) / 2;
> +                       if (unlikely(new_capacity < str->capacity)) {
> +                               new_capacity = min_capacity;
> +                               break;
> +                       }
> +               } while (new_capacity < min_capacity);
> +
> +               /* Jemalloc optimization. Older jemalloc allocates blocks
> +                * large than 4 KiB in 4 KiB chunks, e.g. malloc(5000) will

larger than

> +                * allocate 8 KiB block and 3 KiB will be wasted. Newer
> +                * jemalloc will allocate sizes 5 KiB, 6 KiB (+1 KiB), 7, 8,
> +                * 10 (+2), 12, 14, 16, 20 (+4), 24, 28, 32, 40 (+8), and so
> +                * on. Size classes will also depends on platform

classes will also depend

> +                * and compilation keys.
> +                *
> +                * So optimize for both cases rounding to sizes 4 KiB,
> +                * 8 KiB, 12, ..., 32, 40, 48, 56, etc. It will improve
> +                * jemalloc and will not pessimize other allocators, because
> +                * there is nothing unreasonable in allocating such sizes.
> +                *
> +                * Check for INT_MAX for the only reason that utility

"... only for the only reason that ..." sounds better to me.

> +                * function align() accepts signed integers.
> +                */
> +               overhead_capacity = new_capacity + RALLOC_OVERHEAD;


More information about the mesa-dev mailing list