ICEfaces
  1. ICEfaces
  2. ICE-5140

Improve form serialization performance

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Fix Version/s: 1.8.2-EE-GA, 1.8.3
    • Component/s: Bridge
    • Labels:
      None
    • Environment:
      IE6

      Description

      Ted's findings:

      "There are probably three main phases where we could
      exhibit poor performance in IE: serializing the form,
      updating the browser DOM, and cleaning up listeners.

      By observing the timing of network operations for
      Joanne's ICE-2619 test case (nothing is sent to the server
      until a significant amount of time after a user event),
      it looked worthwhile to measure our serialization
      performance. Here's the simple test case with a large
      table:

      http://server.ice:8888/svn/repo/qa/trunk/Regression/ICE-2619

      Theoretically, we need something like the following
      script to serialize the form, so it was added it to the
      page just as an in-line script. It takes 1500 - 2000
      milliseconds to serialize the same large form:

         var buf = [];
         formElements = form.getElementsByTagName("input");
         var N = formElements.length;
         for(i=0; i < N; i++){
             line = formElements[i].name + "=" + escape(formElements[i].value );
           buf.push(line);
         }
         cat = buf.join("&");

      (I had several false starts here -- using += for string
      concatenation led to 10x - 20x slowdown.)

      In contrast, ICEfaces takes 48000 milliseconds to serialize
      the form.

      In connection.js, we have the following two lines (actually
      one line is pulled out of a function parameter so time
      could be measured for it):

      this.logger.debug('send > ' + compoundQuery.asString());
      var uriEncoded = compoundQuery.asURIEncodedString();

      Each of these lines appears to take about 20s. To verify
      that my timing measurement was not interfering, the
      logging line was commented out, leading to 63s vs 31s
      without the logger call. "Fortunately", IE is slow enough
      that it can be profiled in this test case with a stop watch.
      (I don't believe it's the logging itself causing the
      problem -- compoundQuery.asString() passed to the logger
      is implemented in an expensive way somehow using the
      prototype.js collection operations.)

      So, one strategy would be to replace some of the
      prototype.js collection operations with hand-optimized
      code. At the very least, the logging should be disabled
      when logging output is not visible (if this is not possible
      to detect, logging should be disabled by default). "

        Activity

        Hide
        Mircea Toma added a comment -

        Replace 'inject' operation with a straight forward loop. Use 'join' for concatenating all the serialized parameters. Limit output of Query.asString() method to only 25 lines.

        Show
        Mircea Toma added a comment - Replace 'inject' operation with a straight forward loop. Use 'join' for concatenating all the serialized parameters. Limit output of Query.asString() method to only 25 lines.
        Hide
        Mircea Toma added a comment -

        Fix the limiting algorithm used in Query.asString() method for cases where the number of parameters is smaller than the limit.

        Show
        Mircea Toma added a comment - Fix the limiting algorithm used in Query.asString() method for cases where the number of parameters is smaller than the limit.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mircea Toma
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: