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

LTP: Severe performance bottleneck in XMLEncoder: String.getBytes(encoding)

XMLWordPrintable

    • x86
    • windows_xp

      Name: nt126004 Date: 08/30/2002


      FULL PRODUCT VERSION :
      java version "1.4.1-rc"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
      Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)

      FULL OPERATING SYSTEM VERSION :
      Microsoft Windows XP [Version 5.1.2600]

      ADDITIONAL OPERATING SYSTEMS :
      This problem is platform-neutral.


      A DESCRIPTION OF THE PROBLEM :
      As the size of object graph gets large, the performance of
      XMLEncoder degrades significantly. I use XMLEncoder to
      save data in my application. Archiving of an object graph
      took about 18 sec. It was unacceptable.

      Profiling revealed that the main cause is in a very odd
      place in the XMLEncoder. Please see the following code
      snippet from java.beans.XMLEncoder:

          private void writeln(String exp) {
              try {
                  for(int i = 0; i < indentation; i++) {
                      out.write(' ');
                  }
                  out.write(exp.getBytes(encoding));
                  out.write(" \n".getBytes());
              }
              catch (IOException e) {
                  getExceptionListener().exceptionThrown(e);
              }
          }

      The "exp.getBytes(encoding)" was proved to be occupying
      most of execution time. We created a modified version of
      XMLEncoder that uses a custom version of UTF-8 encoder. By
      doing so, we could reduce the archiving time to 1 sec.

      It's critical problem. We use XMLEncoder to save design of
      visual content composed of java.awt.Components and other
      Java objects. Even with a small content, the performance
      is unacceptable.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Creates a test program to encode a relatively large
      graph. It's enough if it takes over 15sec in your machine.
      2. Profiles it.
      3. See what's eating up the execution time.
      4. Replace getBytes with a custom, simple UTF-8 encoder.
      5. Then profile it again, and compare with the previous
      result.

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      The two results should be significantly different. In my
      case, I experienced archiving time of 18sec and 1sec for
      the same graph.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      The following code demonstrates the performance difference between
      the original and modified versions of XMLEncoder. Statement2
      and NameGenerator2 were just same as java.beans.Statement and NameGenerator.

      Compile with javac -source 1.4 Test.java.
      Run java Test.


      **** see attached jar file

      ---------- END SOURCE ----------

      CUSTOMER WORKAROUND :
      Create an enhanced version extending java.beans.Encoder
      based on the original source code.
      (Review ID: 163565)
      ======================================================================

            malenkov Sergey Malenkov (Inactive)
            nthompsosunw Nathanael Thompson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: