Joe Buck wrote:
> If your program has one or two dominant sprintf calls (as in the example
> that motivated this exercise), it pays off. But for a large program with
> thousands of {,s,f}printf calls, this kind of code size expansion could
> easily hurt instead of help. Without some data showing a payoff for
> large programs, I don't think that this kind of exercise would pay off.
Well, I bumped into this by profiling PostgreSQL, which uses sprintf for
almost all output formatting, like sending results to the client. I've
seen sprintf taking a significant amount of CPU time in oprofile output
in two different test cases. One is exporting a table with timestamp
columns, which uses a format string like "%04d-%02d-%02d %02d:%02d".
Another was loading a large number of records with INSERTs. After each
INSERT statement, a result code is sent to the client, using "INSERT %u
%u". I don't have the numbers at hand, but I can get them if you want.
That's for the large program I'm familiar with. Apparently it plays a
role in Linux as well since they've spent effort on a more performant
implementation. I suspect that many programs have already replaced the
most speed-sensitive sprintf calls with customized code, at the cost of
readability.
> And then consider that any solution has to work correctly with arbitrary
> locales; this could be done with your proposed new library function,
> but it's starting to turn into a rather big project for questionable gain.
The only features in the printf-family of functions that depends on the
locale are the conversion with thousand grouping ("%'d"), and glibc
extension of using locale's alternative output digits ("%Id"). We can
easily just fall back to glibc sprintf in those cases. I was only
thinking of implementing only the most commonly used formats anyway,
initially at least.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
