Apparently the answer had to do with terminal word-wrapping. A good test would be to write the output to a file instead of the terminal and compare the difference in timing.
A graph of wall clock printing speed vs line length for each character would have been highly enlightening. Of course we'd hope anyone who did that would figure it out themselves without posting the question.
If it wasn't a line length issue, it probably would have been
1) Proportional kern'd antialiased fonts some glyphs hardware accelerated some not.
2) Maybe for speed it only caches certain font glyphs but its an anti-accelerant strategy this time. After all, what normal person generates outputs like this?
3) UTF-8 to ASCII and or localization code gone wild or similar misoptimization.
4) You'd like to think a simple string printer and the fancy formatted string printer (aka printf and friends) are separate optimized routines but the simple printer might actually be a degenerate form of the formatted printer and the formatted printer has a severe hangup about certain characters. Maybe # is processed quickly but b gets processed extremely slowly because its regex'ing in a very inefficient way to find the \ as in \b.
5) remember LTRS/FIGS from baudot 5 bit teletype coding? Someone trying something "funny" with 3-d accelerated text rendering treating certain letters as 3-d sprites and some not and its getting all messed up and unoptimized this time. Someones LRU cache of 3-d glyph/sprites isn't as LRU as you'd like to think, perhaps.
