[NTG-pdftex] unbuffered vs. buffered terminal output

Hans Hagen pragma at wxs.nl
Thu Dec 22 10:39:06 CET 2005

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?)


More information about the ntg-pdftex mailing list