Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4046795

FontMetrics.charsWidth() performance is excessively slow



    • b01
    • generic
    • solaris_10
    • Not verified


      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


      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:


      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




            ehawkessunw Eric Hawkes (Inactive)
            amfowler Anne Fowler (Inactive)
            0 Vote for this issue
            0 Start watching this issue