Uploaded image for project: 'Spymemcached Java Client'
  1. Spymemcached Java Client
  2. SPY-127

Address performance of try/catch in isJSONObject checks

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.11.0
    • Component/s: library
    • Security Level: Public
    • Labels:
      None

      Description

      I'm using the CouchBase Java Client and when performing large amounts of set's, the net.spy.memcached.util.StringUtils.isJsonObject() shows up a lot in my profiler as a performance bottleneck due to the overhead of catching exceptions related to attempting to cast strings to an Integer.

      Use a different method of determining whether the incoming string is numeric that doesn't involve throwing and catching errors.

      There are a couple different tickets in existence that suggest this entire method has serious issues and should be scrapped, but I'm unclear on the official response to that since one of the tickets is closed as a duplicate and the other is closed but seems completely unrelated.
      http://www.couchbase.com/issues/browse/JCBC-48
      http://www.couchbase.com/issues/browse/JCBC-41

        Attachments

          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

            Activity

            Hide
            pluppens Philip Luppens added a comment -

            I'd like to give my +1 for this ticket. I did a quick patch of 2.10.5 with a replacement from commons-lang's NumberUtils.isNumber(s), and the performance of my client tripled (from 600 rps to 1900 rps). While I cannot guarantee that this change is correct from a JSON perspective, this is probably as correct as the previous 'new Number(s)/catch NumberFormatException, and the performance is much, much better.

            Show
            pluppens Philip Luppens added a comment - I'd like to give my +1 for this ticket. I did a quick patch of 2.10.5 with a replacement from commons-lang's NumberUtils.isNumber(s), and the performance of my client tripled (from 600 rps to 1900 rps). While I cannot guarantee that this change is correct from a JSON perspective, this is probably as correct as the previous 'new Number(s)/catch NumberFormatException, and the performance is much, much better.
            Hide
            daschl Michael Nitschinger added a comment -

            Sounds good, let's consider this for the next bugfix release.

            Show
            daschl Michael Nitschinger added a comment - Sounds good, let's consider this for the next bugfix release.
            Hide
            pluppens Philip Luppens added a comment - - edited

            Just to keep track of the other issue (since I cannot link issues): JCBC-421

            Show
            pluppens Philip Luppens added a comment - - edited Just to keep track of the other issue (since I cannot link issues): JCBC-421

              People

              • Assignee:
                daschl Michael Nitschinger
                Reporter:
                bdw429s Brad Wood
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes