glassfish
  1. glassfish
  2. GLASSFISH-4949

print(char) does too much memory allocation

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: performance
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      4,949
    • Status Whiteboard:
      Hide

      gfv3-prelude-included

      Show
      gfv3-prelude-included
    • Tags:

      Description

      Hi all,
      I just ran the following Servlet on the latest GlassFish V3 (April 21)

      protected void doGet(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException

      { ServletOutputStream out = response.getOutputStream(); response.setContentType("text/html"); response.setHeader("pragma", "no-cache"); String sizeStr = request.getParameter("size"); int size=0; if (sizeStr!=null) size=Integer.parseInt(sizeStr); for (int i=0; i<size;i++) out.print((char)(255*Math.random())); }

      With an reponse of 100000 (configurable by the size parameter of the servlet)
      bytes 20Mbyte are allocated.

      Profiling indicates that
      org.apache.coyote.tomcat5.CoyoteOutputStream.print(java.lang.String)
      calling

      com.sun.grizzly.util.buf.C2BConverter.convert(java.lang.String)

      which calls

      java.nio.ByteBuffer.wrap(byte[], int, int) 100000 times as well as
      java.nio.CharBuffer.wrap(char[], int, int) 100000 times.

      The response time is 3 times slower than when using write on the Outputstream,
      which allocates almost nothing except a Directbuffer.

      Regards,
      Markus

        Activity

        Hide
        kumara added a comment -

        Exclude from the list being tracked for TP2 release.

        Show
        kumara added a comment - Exclude from the list being tracked for TP2 release.
        Hide
        kumara added a comment -

        Add gfv3-prelude-include to status whiteboard

        Show
        kumara added a comment - Add gfv3-prelude-include to status whiteboard
        Hide
        Scott Oaks added a comment -

        First, it's not correct to compare calling print(c) vs write(c). The former
        must encode the 16-bit character as a series of bytes; the latter can simply
        write out the raw data. So the performance of printing characters vs writing
        binary data will always be drastically different.

        We have in the past explored various ways to get the fastest encoding out of
        the JDK, and I think the current implementation is still optimal. We have filed
        issues against the JDK for its memory use for encoding/decoding strings and are
        tracking those. The JDK isn't well-designed for encoding single characters at a
        time.

        I'm leaving this open for now so we can track the JDK issue, but at present,
        this is the best we can do.

        Show
        Scott Oaks added a comment - First, it's not correct to compare calling print(c) vs write(c). The former must encode the 16-bit character as a series of bytes; the latter can simply write out the raw data. So the performance of printing characters vs writing binary data will always be drastically different. We have in the past explored various ways to get the fastest encoding out of the JDK, and I think the current implementation is still optimal. We have filed issues against the JDK for its memory use for encoding/decoding strings and are tracking those. The JDK isn't well-designed for encoding single characters at a time. I'm leaving this open for now so we can track the JDK issue, but at present, this is the best we can do.
        Hide
        kumara added a comment -

        v3 defect tracking

        Show
        kumara added a comment - v3 defect tracking
        Hide
        kohlerm added a comment -

        Hi,
        Unfortunately, I don't have the profiling snapshot available anymore, but I seem
        to remember that for each char at least one byte[] would be allocated.
        I know that write is supposed to be faster than print because of the additional
        encoding that print has to do, but still a factor of 3 seems to high for me.

        And actually what really hurts it that 20 Mbytes are temporarily allocated just
        to return 10000 bytes.

        Regards,
        Markus

        Show
        kohlerm added a comment - Hi, Unfortunately, I don't have the profiling snapshot available anymore, but I seem to remember that for each char at least one byte[] would be allocated. I know that write is supposed to be faster than print because of the additional encoding that print has to do, but still a factor of 3 seems to high for me. And actually what really hurts it that 20 Mbytes are temporarily allocated just to return 10000 bytes. Regards, Markus
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            Scott Oaks
            Reporter:
            kohlerm
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: