On Wed, Dec 21, 2005 at 10:58:44PM +0000, Paul LeoNerd Evans wrote:
> Yes, I've had a look at that patch. It's not very efficient; it
> allocates a new string buffer big enough to hold the string, then fills
> it, then strdup()s it into the GString, then frees the first buffer.
> That's unnecessary.
>
> My method is:
>
> void g_string_append_vprintf(GString *str, const gchar *fmt, va_list args)
> {
> gsize len = g_printf_string_upper_bound(fmt, args) + 1;
> g_string_maybe_expand(str, len);
> g_vsnprintf(str->str + str->len, len, fmt, args);
> str->len += len;
> }
>
> This doesn't double-allocate the buffer and then incur an unnecessary
> strcpy().Well, I've done some benchmarking in this, and acutally I'd like to retract that statement. My method is slightly faster in a few trivial cases, for example a format with no conversions, or just "%s", by somewhere around 5%. But, this comes at the cost of being quite a bit slower (sometimes 50%) if the format is more complex (I tried "%s%d%s" for example). I suspect this might be because of the extra processing at having to scan the format string and arguments list twice, count up the lengths of string arguments passed in, that sort of thing. This only happens once in the function in its original form. In short; I'll leave it as it is. :) -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
