Amitha Perera <[EMAIL PROTECTED]> writes:
> One other point to keep in mind is the 80/20 (or 90/10, depending on
> what you read) rule. I doubt that even doubling the execution time of
> asprintf would make any significant difference to the user. (I could
> be wrong. Profiling will tell.)
I'm nearly certain that this is true, but as you say, profiling would
tell.
> To reiterate, the code above would in most cases (in gnucash) do
> one malloc, a couple of comparisons, one call to snprintf, and one
> realloc. Not too expensive, I think.
I pretty much agree, though without detailed knowledge of how
expensive things like malloc, realloc, free, etc are, then it's hard
to say for sure what the tradeoffs are (in the libc vs liberty vs your
approach comparison).
Actually, it's too bad we dont have a recalloca. Unless the string
you were building turned out to be *really* large, then that would be
super-fast. Then a final strdup could provide the return pointer.
> This is, of course, the solution I've outlined above. However, I
> have hopefully managed to argue that the solution is not as cheezy
> as you'd imagine. Am I missing something obvious?
Well, I didn't really mean it was *that* cheezy. I suppose I was
envisioning a really smart solution that could make fairly accurate
guesses about the final length based on the format string. However,
in reality, unless you know something detailed about the performance
of malloc/realloc, it's hard to say where the CPU time is best spent.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
