FontMetrics.charsWidth() performance is excessively slow

From billf@doppio Sat Apr 12 22:45:57 1997
Subject: _Very_ significant Font Metrics speedup
To: aim@doppio (Amy Moore)
Cc: billf@doppio (Bill Foote)
Mime-Version: 1.0
X-Status: $$$$
X-UID: 0000000251



Amy,

I've come up with some font metrics improvements that make for a _huge_
speedup in HotJava. A few simple changes will enable HotJava to read
HTML that's mostly text 3x or 4x faster. I would _really_ like to get
these into the next JDK release (1.1.2? 1.2?) -- could I talk to someone
about it this week? (Next week I go on vacation for three weeks, and I
don't want us to miss this one). Who would that be? It looks like
flar originally wrote much of this code, but is he responsible for
maintaining it?

Here are the details: I've implemented the speedups in my local JDK
workspace for Motif. I looked at the Windows code, and it's almost
exactly the same, so it should take very little to do the same thing
in that world. If you'd care to look, here are the files I've changed:

    /home/billf/work/JDK1.1.1/src/share/sun/sun/awt/PlatformFont.java
    /home/billf/work/JDK1.1.1/src/share/sun/sun/awt/CharsetString.java
    /home/billf/work/JDK1.1.1/src/solaris/sun/sun/awt/motif/X11FontMetrics.java
    /home/billf/work/JDK1.1.1/src/solaris/sun/sun/awt/motif/PSPrintStream.java
    /home/billf/work/JDK1.1.1/src/solaris/sun/awt_Font.c
    /home/billf/work/JDK1.1.1/src/solaris/sun/multi_font.c
    /home/billf/work/JDK1.1.1/src/solaris/sun/multi_font.h


All of the files are still checked out, for easy sccs diffing.

These changes make a standalone test program (~billf/tmp/perf/fmtest.java)
go 3x faster. Better, they make our text formatting go 4x faster
(My guess is that the increased boost is due to heap fragmentation. This
improvement is assuming some other HotJava performance enhancements).

Here's what I did:

sun.awt.FontMetrics.charsWidth(char[], int, int) was the culprit. Most
of it was implemented in native code, but that native code made
a number of calls up to Java. Calling Java from native code is, of
course, heinously slow... Moving this code from C to Java resulted in a 30%
speedup (the standalone program that did nothing but call charsWidth
went from 6.9s to 4.7s). (Yes, LLNI will solve this too, but this
code really belongs in Java anyway -- it's simple, and consists almost
entirely of calls to Java).
 
Once that was done, it was _much_ easier to approach the other problem:
Excessive copying. The char[] we pass in was being converted to a
StringBuffer, then to a String (in sun.awt.CharsetString), and then
converted back to a char[] on its way to being converted into a
byte[] (for i18n), with an extra CharSetString[] and a Vector thrown
on the heap for good measure. Changing CharsetString (which is an
implementation class that's only used in three or four places) to
work in terms of char[], offset and length and getting rid of the
Vector in the common case where it only has one element made a
_big_ difference. That standalone program went down to 2.4s.


BTW, I do realize that you guys have been _much_ too busy with other
issues to even look at performance (as have we). This particular
optimization, however, is in one of those key areas that make an
absolutely huge difference, which is why I'd like to get it in.
It also results in code that's simpler, more compact and more
maintainable.