This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Preparsing sprintf format strings


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]