On the printing slowness of Postscript produced by the JVM from calls to Graphics.drawString() (Linux/Unix)

Question

Happy new year,
before the holidays my attention was drawn to an issue that supposedly the Postscript produced by the JVM is too big and hence too slow.  Here are my findings.
The issue
Text printing via CUPS to native Postscript printers can be slow. Printing a terms and conditions page (17000 characters/page) takes three and a half minutes to print on a Dell 2330 dn laser printer (96 MB,Max speed 33 ppm). The file is about 8 MB in size. To contrast that, rendering the text to a buffered image with 300 DPI and printing the result produces 7 MB of output which prints in 30 seconds on the same printer. More measures for different printers and documents can be found at the end of this post. The issues is registered as  "JDK-4627340 : RFE: A way to improve text printing performance for postscript devices" (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4627340) and the proposed workaround is to use printer fonts.
Side remark regarding the workaround
There is a regression that prevents the workaround from working (bug 9008662 at Sun (not yet visible),  bug 8023990 at OpenJDK (https://bugs.openjdk.java.net/browse/JDK-8023990). Without knowing what other bad side effects this might have, the issue can be resolved by setting the property "sun.awt.fontconfig". On my system I set it to the location of a "fontconfig.properties" of a JVM that does not have the bug (e.g. /home/alex/openjdk_7_b147_jun_11/openjdk/build/linux-i586/bin/java -Dsun.awt.fontconfig="/etc/java-6-openjdk/fontconfig.properties" Print2DtoStream). I also successfully tested the workaround on an Oracle JVM 1.7.0_03-b04.
Back to the main topic
How the JVM draws text if it can't use a standard printer font
Text is drawn with postscript path drawning commands such as "moveto", "lineto" or "curveto". As an example consider the word "ll" which looks something like this:
%N->short for "newpath"
N
%paint first "l"
%M->short for "moveto"
0.76875 11.06 M
%L->short for "lineto"
0.76875 2.468 L
1.823 2.468 L
1.823 11.06 L
0.76875 11.06 L
%p->short for "closepath"
P
%paint second "l"
3.649 11.06 M
3.649 2.468 L
4.703 2.468 L
4.703 11.06 L
3.649 11.06 L
P
The same text could be printed with a printer font using the command "(ll) show" which is much more compact but is available in Java only for the Postscript standard fonts and it isn't working at all right now as explained above.
Is it the file size?
My first thought was that the file size was the source of of slowness and so I wrote a small processor that would detect glyphs, normalize*1 them and place them in a dictionary. Recurring references to the same glyph were replaced by a dictionary reference  (This is incidentally the fix proposed by the original author of RFE 4627340). This shrunk the file to about 11% of the original size but the processing time surprisingly doubled.
*1: With "normalizing" I mean applying a translation transform so that the smallest coordinates in the contours of a glyph are exactly 0. In addition I experimented with performing a normalizing scale transform so that all coordinates lie between 0 and 1 so that identical glyphs are detected at arbitrary positions and at different font sizes.
That led to the question to why there is such a big difference in performance between a Type 1 font dictionary and a self constructed dictionary since both contain basically the same drawing instructions. The difference is apparently that fonts are cached and user drawings are not unless explicitly told.
The Postscript "ucache" instruction
Postscript level 2 introduces the "ucache" instruction which seems to be defined for precisely this kind of problem. From the documentation:
"Some PostScript programs define paths that are repeated many times. To optimize the interpretation of such paths, the PostScript language provides a facility called the user path cache. This cache, analogous to the font cache, retains the results from previously interpreted user path definitions. When the PostScript interpreter encounters a user path that is already in the cache, it substitutes the cached results instead of reinterpreting the path definition. "
After adding "ucache" instructions to my filter the speed improved by factor 10.
To illustrate the said the "ll" text from above looked as follows after the transformation:
%definition of the glyph "l" named "p0"
/p0
ucache
0.000 0.000 1.054 8.592 setbbox
0.000 8.592 moveto
0.000 0.000 lineto
1.054 0.000 lineto
1.054 8.592 lineto
0.000 8.592 lineto
closepath
} cvlit def
G
N
0.769 2.468 translate
%draw "l" at 0.769 2.468
p0 ufill
-0.769 -2.468 translate
3.649 2.468 translate
%draw "l" at 3.649 2.468
p0 ufill
-3.649 -2.468 translate
For ucached shapes there is a special compact representation so that the same can be written as follows:
/p0
0.000 0.000 1.054 8.592
0.000 8.592
0.000 0.000
1.054 0.000
1.054 8.592
0.000 8.592
} cvlit def
G
N
0.769 2.468 translate
p0 ufill
-0.769 -2.468 translate
3.649 2.468 translate
p0 ufill
-3.649 -2.468 translate
Interestingly the speed improvement remained the same on a Chinese report that had hardly any character reuse. Upon this observation I changed the filter to not use a dictionary but so simply instruct the interpreter to cache each glyph definition and the performance remained nearly the same.
The initial "ll" text from above looks as follows after this transformation:
N
%paint first "l" cached
0.76875 2.468 1.823 11.06
0.76875 11.06
0.76875 2.468
1.823 2.468
1.823 11.06
0.76875 11.06
} ufill
%paint second  "l" cached
3.649 2.468 4.703 11.06
3.649 11.06
3.649 2.468
4.703 2.468
4.703 11.06
3.649 11.06
} ufill
Note that I didn't normalize the shapes.
Why does this improve the performance so vastly if the shape is drawn only once? For a while I thought perhaps that the interpreter would consider two paths which differ only by a translation as being the same but rereading the documentation and looking at the Chinese example in which nearly all characters are unique, disproves this. The relevant part of the documentation reads:
"Caching is based on the value of a user path object. That is, two user paths are considered the same for caching purposes if all of their corresponding elements are equal, even if the objects themselves are not.
A user path placed in the cache need not be explicitly retained in virtual memory. An equivalent user path appearing literally later in the program can take advantage of the cached information. Of course, if it is known that a given user path will be used many times, defining it explicitly in VM avoids creating it multiple times.
User path caching, like font caching, is effective across translations of the user coordinate system, but not across other transformations, such as scaling or rotation. In other words, multiple instances of a given user path painted at different places on the page will take advantage of the user path cache when the current transformation matrix has been altered only by translate. If the CTM has been altered by scale or rotate , the instances will be treated as if they were described by different user paths."
An explanation that would fit the findings
The rasterizer renders the page multiple time (perhaps in order to save memory and produce horizontal strips). On the first rendering the cache is filled and reused on the subsequent renderings thereby improving performance even if all cached items are used only once.
Based upon this theory I hoped that the strip height would grow if I added more memory to the printer but this was not the case on the two printers for which I had memory to test with. Even substantial changes to the available memory (e.g. going from 32 MB to 96 MB) had no impact whatsoever on the performance.
Summary
The issue is not related to the file size as the original requester suspected but very likely due to the uncached rendering. Caching of glyphs can be achieved by using the "ucache" instruction or perhaps by placing the glyphs in font dictionaries and using the "show" operator.
Although reported in 2003, time is apparently not healing this quick enough since printers in the 10,000$ class like the Sharp MX2310U still take a full minute to print 10 pages and a desktop printer may be blocked for over an hour for the same document.
We will now try to use the CUPS filter and leave the printers configured as Postscript printers. If there is interest I can post the single file source of a CUPS filter that performs the inline conversion described. Apart from libl it requires no additional libraries and written using flex it is reasonably lightweight and fast.
I would appreciate any opinion on whether or not the proposed workaround for bug 8023990 (https://bugs.openjdk.java.net/browse/JDK-8023990), namely having the system property "sun.awt.fontconfig" pointing to a working fontconfig.properties of a previously installed and working 1.6 version file, is safe.
Measures (Appendix)
"Terms and Conditions" report
Testing a single page "Terms and Conditions" report in "Arial" 8pt (I am aware that "Helvetica" is width compatible and nearly looks the same but in this particular case the line height was also relevant and as explained above, printer fonts are currently not working). The page contains 17000 characters of which some parts are bold and some italic. This is a real world example and to make things worse the requirement is to print the text on the backside of every page on a certain class of reports. I am aware that this is a bit extreme but I also felt that I couldn't dismiss it as being unreasonable.
File "Arial.ps" (7.5 MB Unmodified output of the JVM)
Printer
Printing time
Dell 2330dn 32MB/96MB
3:50 minutes
Lexmark X658de (55 ppm, aprox. 5,000$)
  1:45 minutes
HP LaserJet 4240n 64 MB
1:12 minutes
Kyocera Taskalfa 300ci (30 PPM, aprox. 8,000$)
1 minute
HP Color LaserJet 4650 dn 128/384MB
51 seconds
Sharp MX 2310U 512MB (55ppm,  aprox. 10,000$)
31 seconds
Arial_inline.ps (8 MB contains "ucache" without normalization and without dictionary)
Printer
Printing time
32MB/96MB
30seconds/30seconds (Improvement by factor 7.7)
Lexmark X658de (55 ppm, aprox. 5,000$)
  15 seconds (Improvement by factor 7)
HP LaserJet 4240n 64 MB
47 seconds (Improvement by factor 1.5)
Kyocera Taskalfa 300ci (30 PPM, aprox. 8,000$)
20 seconds (Improvement by factor 5)
HP Color LaserJet 4650 dn 128/384MB
46 seconds (Improvement by factor 1.1)
Sharp MX 2310U 512MB (55ppm,  aprox. 10,000$)
14 seconds (Improvement by factor 2)
Asian characters test
Testing 10 pages of Asian characters in the font "WenQuanYi Zen Hei" 12pt where each page contains 49 lines by 40 unique characters. The document contains the 30,000 characters between unicode 0x4e00 and 0x9fff. This is a nonsense stress test but it illustrates  that the "ucache" speedup works even though no character is repeated in the report.
Asian.ps  (52 MB Unmodified output of the JVM)
Printer
Printing time
Dell 2330dn 32MB/96MB
64 minutes
Lexmark X658de (55 ppm, aprox. 5,000$)
Not measured
HP LaserJet 4240n 64 MB
11 minutes
Kyocera Taskalfa 300ci (30 PPM, aprox. 8,000$)
Not measured
HP Color LaserJet 4650 dn 128/384MB
9:13 minutes
Sharp MX 2310U 512MB (55ppm,  aprox. 10,000$)
4:08 minutes
Asian_inline.ps (54 MB contains "ucache" without normalization and without dictionary)
Printer
Printing time
32MB/96MB
5:30 minutes (Improvement by factor 11.6)
Lexmark X658de (55 ppm, aprox. 5,000$)
Not measured
HP LaserJet 4240n 64 MB
3:48 minutes (Improvement by factor 2.9)
Kyocera Taskalfa 300ci (30 PPM, aprox. 8,000$)
Not measured
HP Color LaserJet 4650 dn 128/384MB
2:46 minutes (Improvement by factor 3.4)
Sharp MX 2310U 512MB (55ppm,  aprox. 10,000$)
48 seconds (Improvement by factor 5)

Answer 1

Hi Sven,
Will putting the boilerplate in the trailer section allow me to still have it appearing on the back page of the main report? This is where it needs to be as far as the printed report goes - it is duplexed.
Regards
Lanny