----- Original Message ----- > The ralloc string appending functions were originally intended for > simple, non-hot-path uses like printing to an info log. > > Cuts Unigine Tropics load time by around 20% (6 seconds). > > Signed-off-by: Kenneth Graunke <[email protected]> > --- > src/glsl/glcpp/glcpp-parse.y | 48 > ++++++++++++++++++++++------------------- > src/glsl/glcpp/glcpp.h | 2 + > 2 files changed, 28 insertions(+), 22 deletions(-) > > It would be far nicer if we had a string class that stored the length > and > had asprintf_append-style methods. Like csString in Crystal Space. > But > that's a more invasive change, I think. STL has the ostringstream > class > for this exact purpose, but that would require rewriting everything > to use > C++ style IO, and I'm loathe to do that (mostly because we don't use > it > anywhere else).
Yes, while C++ style IO allows one to seemingly print user defined types just as easily as basic types, when one wants precise formatting for basic types, it is much more inconvenient and verbose than printf-like format specificiers. FWIW, I wrote a small class that wraps std::vector, provides std::string like methods, and allows printf-like specifiers to aid manipulating paths in apitrace, on https://github.com/apitrace/apitrace/blob/master/common/os_string.hpp , and as you can see it doesn't take much. But I think that in this particular the route you took of using ralloc_asprintf_rewrite_tail seems a more natural choice. I noticed that many of the arguments are constant strings. I think it might be worth to try splitting the implementation of these functions such that the strlen() call happens in an inline function in src/glsl/ralloc.h, allowing the strlen() of constant strings to be determined at compile time. BTW, your previous patch seems a good cleanup too. Jose _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
