![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Hartmut Henkel wrote:
following trivial observation i made (several runs):
$ time pdfetex samplepdf
real 0m2.536s real 0m2.605s real 0m2.737s real 0m2.654s
$ time pdfetex samplepdf | buffer
real 0m0.900s real 0m1.035s real 0m0.900s real 0m0.913s
the speed gain is impressive here, also with other files from daily business and for longer runs. Same if i write
$ pdfetex samplepdf > xxx
So at least here pdfetex spends lots of time just for unbuffered talk to the terminal. And it's faster with a smaller window.
Maybe we should think of implementing buffered writing? See e. g. man 3 setbuf. The problem is that it should fflush() in case of errors and switch to unbuffered. And maybe it should fflush() also after a certain time of say 0.5 s, which would require select().
Has anybody similar statistics?
it is a known fact that the speed depends on the kind of terminal; when one has a console that uses outline fonts or is graphical in nature (e.g. on the mac) the penalty can be huge; try batchmode -) on my machine (windows xp) the size of the windows does not matter that much (i use 5000 line scrollbacks) maybe this 'locale' thing is interfering as well? are chars written one by one or by line? maybe there is some intermediate way possible: - normal messages -> buffered - immediate/write16 -> flush pending messages and write unbuffered (btw, in your case, i'd try to optimize the terminal fonts; did you compare pdfetex with e.g. compiling pdftex?) Hans