🚀 go-pugleaf

In article <18036@ucbvax.BERKELEY.EDU> shebanow@ji.Berkeley.EDU.UUCP (Mike Shebanow) writes:
>Every time I trace a program which uses stdio to any great degree, I find
>printf to be the worst offender (with regard to time consumed). In fact,
>I have seen programs which spend 30% of their time in printf (actually
>_doprnt). In the code I have optimized, I usually try to eliminate the
>use of printf (which can make the code rather opaque). This does result
>in 10-20% improvements in speed. The most obvious use of new string
>processing instructions would be to improve the performance of printf.
>Has anyone done this?

Here at Project Synthesis we found that out a while back. It is pretty
strange to think of it that way, but yes, Printf and friends are
compute bound, not I/O bound. We have experimented with a number of
solutions, including a hardware printf coprocessor for the 68020.
Predictably, it improved performance quite a bit. We also have tried
using specially coded versions of printf in assembly language that we
passed through a (very time expensive) exhaustive search optimiser and
the results were also pretty good.

Perry Metzger