Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.1.2.1
    • Fix Version/s: 10.1.3.1
    • Component/s: Network Server
    • Labels:
      None
    • Bug behavior facts:
      Performance

      Description

      writeSQLCAGRP() writes Strings into the message being built. Profiling shows that it is more expensive to write a String than a byte[] because the String must be converted to UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and this is done by either writing a String constant, or the return value from SQLException.getSQLState(). For the common case where there is no exception (SQLState = 5xspace), or the exception is a "dummy" exception (SQLState=00000 or 02000, End of Data), this is wasteful because the String has to be converted to byte[] each time, and in the case of the dummy exception, a new String object will be created each time getSQLState() is called, even if the exception object is the same (there is no caching, which is reasonable since exceptions are meant to be thrown, not kept around for a long time).

      A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().

      If writeSQLCAGRP() is called with no SQLException (null) there is no attempt to put an internationalized error message into the outgoing message (The third argument to writeSQLCAXGRP() is null). This is reasonable, but the same optimization is not done when the exception is one of the dummy exceptions mentioned previously. In this case an internationalized version of the message "End of Data" is constructed and inserted into the message. It would be better to call writeSQLCAXGRP(..,null,..) in this case as well, since it isn't needed by the client in this case.

      Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values that also can be stored as byte[] constants, and written faster with writeBytes()

      1. derby-825.diff
        9 kB
        Dyre Tjeldvoll
      2. derby-825.stat
        0.4 kB
        Dyre Tjeldvoll
      3. derbynetclientmats_report.txt
        203 kB
        Dyre Tjeldvoll

        Activity

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        8h 35m 1 Dyre Tjeldvoll 20/Jan/06 01:54
        In Progress In Progress Resolved Resolved
        4d 15h 57m 1 Bernt M. Johnsen 24/Jan/06 17:52
        Resolved Resolved Closed Closed
        1d 1h 27m 1 Dyre Tjeldvoll 25/Jan/06 19:20
        Closed Closed Reopened Reopened
        75d 6h 31m 1 Dyre Tjeldvoll 11/Apr/06 02:51
        Reopened Reopened Closed Closed
        2m 58s 1 Dyre Tjeldvoll 11/Apr/06 02:54
        Gavin made changes -
        Workflow jira [ 12345906 ] Default workflow, editable Closed status [ 12797625 ]
        Dag H. Wanvik made changes -
        Derby Categories [Performance]
        Dag H. Wanvik made changes -
        Component/s Performance [ 11709 ]
        Dyre Tjeldvoll made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Closed [ 6 ]
        Dyre Tjeldvoll made changes -
        Affects Version/s 10.1.2.1 [ 12310615 ]
        Fix Version/s 10.1.3.0 [ 12310616 ]
        Hide
        Dyre Tjeldvoll added a comment -

        Setting fixin to 10.1.3.0. But is not extremely important so it could be posponed if it is difficult to merge.

        Show
        Dyre Tjeldvoll added a comment - Setting fixin to 10.1.3.0. But is not extremely important so it could be posponed if it is difficult to merge.
        Dyre Tjeldvoll made changes -
        Status Closed [ 6 ] Reopened [ 4 ]
        Resolution Fixed [ 1 ]
        Hide
        Dyre Tjeldvoll added a comment -

        Reopen to set fixin

        Show
        Dyre Tjeldvoll added a comment - Reopen to set fixin
        Dyre Tjeldvoll made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Dyre Tjeldvoll added a comment -

        Committed by Bernt Johnsen

        Show
        Dyre Tjeldvoll added a comment - Committed by Bernt Johnsen
        Bernt M. Johnsen made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Bernt M. Johnsen added a comment -

        Comitted as #370806 Fri Jan 20 14:34:53 CET 2006 bernt
        The log message errouneous and ended up under DERBY-815.

        Show
        Bernt M. Johnsen added a comment - Comitted as #370806 Fri Jan 20 14:34:53 CET 2006 bernt The log message errouneous and ended up under DERBY-815 .
        Dyre Tjeldvoll made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Dyre Tjeldvoll made changes -
        Attachment derby-825.diff [ 12322112 ]
        Attachment derbynetclientmats_report.txt [ 12322113 ]
        Attachment derby-825.stat [ 12322111 ]
        Hide
        Dyre Tjeldvoll added a comment -

        derbynetclientmats had 3 failures also seen in nightly testing. derbynetmats had no failures.

        Show
        Dyre Tjeldvoll added a comment - derbynetclientmats had 3 failures also seen in nightly testing. derbynetmats had no failures.
        Dyre Tjeldvoll made changes -
        Component/s Performance [ 11709 ]
        Priority Major [ 3 ] Minor [ 4 ]
        Description writeSQLCAGRP() writes Strings into the message being built. Profiling shows that it is more expensive to write a String than a byte[] because the String must be converted to UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and this is done by either writing a String constant, or the return value from SQLException.getSQLState(). For the common case where there is no exception (SQLState = 5xspace), or the exception is a "dummy" exception (SQLState=00000 or 02000, End of Data), this is wasteful because the String has to be converted to byte[] each time, and in the case of the dummy exception, a new String object will be created each time getSQLState() is called, even if the exception object is the same (there is no caching, which is reasonable since exceptions are meant to be thrown, not kept around for a long time).

        A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().

        If writeSQLCAGRP() is called with no SQLException (null) there is no attempt to put an internationalized error message into the outgoing message (The third argument to writeSQLCAXGRP() is null). This is reasonable, but the same optimization is not done when the exception is one of the dummy exceptions mentioned previously. In this case an internationalized version of the message "End of Data" is constructed and inserted into the message. It would be better to call writeSQLCAXGRP(..,null,..) in this case as well, since it isn't needed by the client in this case.

        Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values that also can be stored as byte[] constants, and written faster with writeBytes()
         
        Component/s Network Server [ 11410 ]
        Environment
        Dyre Tjeldvoll made changes -
        Field Original Value New Value
        Assignee Dyre Tjeldvoll [ dyret ]
        Dyre Tjeldvoll created issue -

          People

          • Assignee:
            Dyre Tjeldvoll
            Reporter:
            Dyre Tjeldvoll
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development