Path: utzoo!attcan!uunet!cs.utexas.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: parsing the format string at compile time...
Summary: Is a good idea, for an ANSI compiler.
Message-ID: <1989Oct16.034003.2599@twwells.com>
Date: 16 Oct 89 03:40:03 GMT
References: <705@nixbur.UUCP> <10082@venera.isi.edu>
Organization: None, Ft. Lauderdale, FL
Lines: 34

In article <10082@venera.isi.edu>, lmiller@venera.isi.edu (Larry Miller) writes:
:         Parsing the format string is so incredibly trivial
:         that there can be no advantage of having to make
:         separate function calls for each data type like this.

How about decreasing the running time of a program to 40% of its
original time? This was the improvement I got for one program, on a
VAX under IS/3, when I replaced the printf with my own routine. How
about to 30%? This was the result of yesterday's recoding on my
Microport SysV/386 3.0e. Both cases used nothing more difficult than
%d and %s.

Printf does two things: interprets the format string, a not entirely
trivial task. And: formats the results USING GENERAL PURPOSE ROUTINES.
That latter is critical. Formatting with %d can take about ten times
as long as doing it yourself.

A smart printf could special case these and use a separate routine
for them. This could make an amazing difference in the performance of
printf.

Whether doing this at compile time instead of at run time is a good
idea I don't know. Before I'd say anything on that, I'd want to
experiment.

However, there is one good reason for parsing the string at compile
time: it becomes possible to type check the arguments against the
string. Even if no special code were generated, this would be very
valuable, eliminating many bugs and portability problems. Doing this
is legal under ANSI C.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com