On Jan 1, 2017 4:41 AM, "Kenneth Graunke" <kenn...@whitecape.org> wrote:
On Sunday, January 1, 2017 1:34:27 AM PST Marek Olšák wrote: > From: Marek Olšák <marek.ol...@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 <kenn...@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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
