[Mesa-dev] [PATCH 2/7] glsl/glcpp: use ralloc_sprint_rewrite_tail to avoid slow vsprintf

Marek Olšák maraeo at gmail.com
Sun Jan 1 11:18:28 UTC 2017


On Jan 1, 2017 4:41 AM, "Kenneth Graunke" <kenneth at whitecape.org> wrote:

On Sunday, January 1, 2017 1:34:27 AM PST Marek Olšák wrote:
> From: Marek Olšák <marek.olsak at amd.com>
>
> This reduces compile times by 4.5% with the Gallium noop driver and
> gl_constants::GLSLOptimizeConservatively == true.

Compile times of...what exactly?  Do you have any statistics for this
by itself?


I always use my shader-db with almost 30k shaders and I used the time
command.


Assuming we add your helper, this patch looks reasonable.
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

BTW, I suspect you could get some additional speed up by changing

   parser->output = ralloc_strdup(parser, "");

to something like:

   parser->output = ralloc_size(parser, strlen(orig_concatenated_src));
   parser->output[0] = '\0';

to try and avoid reallocations.  rewrite_tail will realloc just enough
space every time it allocates, which means once you reallocate, you're
going to be calling realloc on every single token.  Yuck!

ralloc/talloc's string libraries were never meant for serious string
processing like the preprocessor does.  They're meant for convenience
when constructing debug messages which don't need to be that efficient.

Perhaps a better approach would be to have the preprocessor do this
itself.  Just ralloc_size() output and initialize the null byte.
reralloc to double the size if you need more space.  At the end of
preprocessing, reralloc to output_length at the end of free any waste
from doubling.

I suspect that would be a *lot* more efficient, and is probably what
we should have done in the first place...


Sure. However, realloc is a no-op when there is free space after the
allocation. It's a useless call, but it doesn't look too bad in a profiler.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170101/183e3caf/attachment.html>


More information about the mesa-dev mailing list