Loading ...
Sorry, an error occurred while loading the content.

JSWOOF - New JSON Parser For FLEX.

Expand Messages
  • W
    Hi all, I have been working on a new JSON Parser for FLEX. Called JSWOOF. The Library is fully complient with the JSON spec. and has been fully optimized for
    Message 1 of 5 , Apr 28 1:28 AM
    View Source
    • 0 Attachment
      Hi all,

      I have been working on a new JSON Parser for FLEX.
      Called JSWOOF.

      The Library is fully complient with the JSON spec. and has
      been fully optimized for fast encoding and decoding of streams.

      you can find it at:
      http://www.waynemike.co.uk/jswoof
    • Martin Cooper
      ... Can you say some more about the way you tested performance against corelib (presumably as3corelib .92.1)? Apart from purely size, I m interested in the
      Message 2 of 5 , Apr 28 11:23 AM
      View Source
      • 0 Attachment
        On Tue, Apr 28, 2009 at 1:28 AM, W <wayne.ivor@...> wrote:

        > Hi all,
        >
        > I have been working on a new JSON Parser for FLEX.
        > Called JSWOOF.
        >
        > The Library is fully complient with the JSON spec. and has
        > been fully optimized for fast encoding and decoding of streams.


        Can you say some more about the way you tested performance against 'corelib'
        (presumably as3corelib .92.1)? Apart from purely size, I'm interested in the
        characteristics of the JSON structures you used (e.g. depth of nesting,
        ratio of objects to arrays, object sizes, whitespace / density, etc.).

        --
        Martin Cooper


        you can find it at:
        > http://www.waynemike.co.uk/jswoof
        >
        >
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • W
        Testing was not done at a functional. For example i did not test my string-encoding function against core-libs string-encoding function, etc. but instead
        Message 3 of 5 , Apr 28 1:33 PM
        View Source
        • 0 Attachment
          Testing was not done at a functional. For example i did not test my string-encoding function against core-libs string-encoding function, etc. but instead tested the overall speed of my encoding/decoding processes against core-libs.

          Strings where one area i found to have a serious impact on the processor, and this was mainly due to the way the tokenizer was setting flag states. and the way most parsers handle the strings in general. For example testing for white-space in JSWOOF has no comparison tests, but instead uses bitwise operations.

          As for the rest of the encoding and decoding mechanism, it is handled recursively, so a gain once becomes a gain over and over again. Each time that optimized area gets called.

          You asked about testing on arrays, and objects. But these are merely a collection of sub entities [strings, number, Boolean, etc]. So density would also only trigger execution of the same optimized sub-entity functions.

          Wayne Mike.


          --- In json@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
          >
          > On Tue, Apr 28, 2009 at 1:28 AM, W <wayne.ivor@...> wrote:
          >
          > > Hi all,
          > >
          > > I have been working on a new JSON Parser for FLEX.
          > > Called JSWOOF.
          > >
          > > The Library is fully complient with the JSON spec. and has
          > > been fully optimized for fast encoding and decoding of streams.
          >
          >
          > Can you say some more about the way you tested performance against 'corelib'
          > (presumably as3corelib .92.1)? Apart from purely size, I'm interested in the
          > characteristics of the JSON structures you used (e.g. depth of nesting,
          > ratio of objects to arrays, object sizes, whitespace / density, etc.).
          >
          > --
          > Martin Cooper
          >
          >
          > you can find it at:
          > > http://www.waynemike.co.uk/jswoof
          > >
          > >
          > >
          > >
          > >
          > > ------------------------------------
          > >
          > > Yahoo! Groups Links
          > >
          > >
          > >
          > >
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • Martin Cooper
          ... The reason I m asking is because a JSON object with a flat 10,000 name / value pairs would illustrate different performance characteristics than 10,000
          Message 4 of 5 , Apr 28 8:30 PM
          View Source
          • 0 Attachment
            On Tue, Apr 28, 2009 at 1:33 PM, W <wayne.ivor@...> wrote:

            > Testing was not done at a functional. For example i did not test my
            > string-encoding function against core-libs string-encoding function, etc.
            > but instead tested the overall speed of my encoding/decoding processes
            > against core-libs.
            >
            > Strings where one area i found to have a serious impact on the processor,
            > and this was mainly due to the way the tokenizer was setting flag states.
            > and the way most parsers handle the strings in general. For example testing
            > for white-space in JSWOOF has no comparison tests, but instead uses bitwise
            > operations.
            >
            > As for the rest of the encoding and decoding mechanism, it is handled
            > recursively, so a gain once becomes a gain over and over again. Each time
            > that optimized area gets called.
            >
            > You asked about testing on arrays, and objects. But these are merely a
            > collection of sub entities [strings, number, Boolean, etc]. So density would
            > also only trigger execution of the same optimized sub-entity functions.


            The reason I'm asking is because a JSON object with a flat 10,000 name /
            value pairs would illustrate different performance characteristics than
            10,000 objects with one name / value pair each, one nested within the other,
            within the other, etc., all the way down the chain. Other types of
            structures would illustrate different performance characteristics again.
            That's why just giving raw times and sizes doesn't tell us very much about
            what it's faster at and what it might not be quite as fast at.

            --
            Martin Cooper



            > Wayne Mike.
            >
            > --- In json@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
            > >
            > > On Tue, Apr 28, 2009 at 1:28 AM, W <wayne.ivor@...> wrote:
            > >
            > > > Hi all,
            > > >
            > > > I have been working on a new JSON Parser for FLEX.
            > > > Called JSWOOF.
            > > >
            > > > The Library is fully complient with the JSON spec. and has
            > > > been fully optimized for fast encoding and decoding of streams.
            > >
            > >
            > > Can you say some more about the way you tested performance against
            > 'corelib'
            > > (presumably as3corelib .92.1)? Apart from purely size, I'm interested in
            > the
            > > characteristics of the JSON structures you used (e.g. depth of nesting,
            > > ratio of objects to arrays, object sizes, whitespace / density, etc.).
            > >
            > > --
            > > Martin Cooper
            > >
            > >
            > > you can find it at:
            > > > http://www.waynemike.co.uk/jswoof
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > ------------------------------------
            > > >
            > > > Yahoo! Groups Links
            > > >
            > > >
            > > >
            > > >
            > >
            > >
            > > [Non-text portions of this message have been removed]
            > >
            >
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >


            [Non-text portions of this message have been removed]
          • W
            Any entity that could be nested had to be tested rigorously as this type of structuring naturally slows down processing. The project i originally designed
            Message 5 of 5 , Apr 29 12:23 PM
            View Source
            • 0 Attachment
              Any entity that could be nested had to be tested rigorously as this type
              of structuring naturally slows down processing.

              The project i originally designed JSWOOF for uses allot of nested arrays
              Some times going more than 50 children deep.

              Nested objects were also used alot throughout the project, mainly to populate data-grids. But bear in mind that these grids had twistable rows with a maximum of 20 twists.

              The project started out life using the core-lib library, hence the reason why i
              Compared results with this library on the JSWOOF website.

              i noticed things slow down using the core-lib library initially when we started
              Nesting the JSON we were using. i.e.

              fig 1:
              ------
              {
              "name" : "value",
              "name" : "value",
              "name" : array[...]
              }

              Something similar to the above really made core-lib slow down. It just did not like all
              that white space. And in actual fact there were no carriage returns in the JSON we
              Passed to core-lib as that would cause it to crash, so it only contianed spaces. JSWOOF
              Will however handle fully structured JSON as shown in fig 1 with carriage returns and tabs included.

              So as stated in my previous post, this was the first issue I came accross, and the way
              JSWOOF gets around this is to use bit-wise operations to check character types.

              The second thing i noticed was that objects and arrays work in a very similar fashion
              but for conversation sake we will concentrate on arrays only. take a look a fig 2.

              fig 2 - typical JSON Array creation.
              -----
              a) Allocate memory for array.
              b) Insert element into array.
              c) Move onto next possible element - goto (b).

              Now if this were a nested array or object we would have to allocate some space for the
              new node so fig2 would become.

              a) Allocate memory for array.
              b) Insert element into array.
              c) Move onto next possible element
              c1) Element = array (goto a)
              Element = xxx

              As you can see memory allocation is being done over and over again for each sub array, and this
              seriously adds to the processing time. JSWOOF does not take this approach it instead creates
              a small pool of arrays and objects for use by the object parser and array parser see fig3.

              fig3
              ----
              a) get array from pool.
              b) insert element into array.
              c) move onto next possible element
              c1) element = array (goto a)
              elemtnt = xxx

              Wayne IV Mike.


              --- In json@yahoogroups.com, Martin Cooper <mfncooper@...> wrote:
              >
              > On Tue, Apr 28, 2009 at 1:33 PM, W <wayne.ivor@...> wrote:
              >
              > > Testing was not done at a functional. For example i did not test my
              > > string-encoding function against core-libs string-encoding function, etc.
              > > but instead tested the overall speed of my encoding/decoding processes
              > > against core-libs.
              > >
              > > Strings where one area i found to have a serious impact on the processor,
              > > and this was mainly due to the way the tokenizer was setting flag states.
              > > and the way most parsers handle the strings in general. For example testing
              > > for white-space in JSWOOF has no comparison tests, but instead uses bitwise
              > > operations.
              > >
              > > As for the rest of the encoding and decoding mechanism, it is handled
              > > recursively, so a gain once becomes a gain over and over again. Each time
              > > that optimized area gets called.
              > >
              > > You asked about testing on arrays, and objects. But these are merely a
              > > collection of sub entities [strings, number, Boolean, etc]. So density would
              > > also only trigger execution of the same optimized sub-entity functions.
              >
              >
              > The reason I'm asking is because a JSON object with a flat 10,000 name /
              > value pairs would illustrate different performance characteristics than
              > 10,000 objects with one name / value pair each, one nested within the other,
              > within the other, etc., all the way down the chain. Other types of
              > structures would illustrate different performance characteristics again.
              > That's why just giving raw times and sizes doesn't tell us very much about
              > what it's faster at and what it might not be quite as fast at.
              >
              > --
              > Martin Cooper
              >
              >
              >
              > > Wayne Mike.
              > >
              > > --- In json@yahoogroups.com, Martin Cooper <mfncooper@> wrote:
              > > >
              > > > On Tue, Apr 28, 2009 at 1:28 AM, W <wayne.ivor@> wrote:
              > > >
              > > > > Hi all,
              > > > >
              > > > > I have been working on a new JSON Parser for FLEX.
              > > > > Called JSWOOF.
              > > > >
              > > > > The Library is fully complient with the JSON spec. and has
              > > > > been fully optimized for fast encoding and decoding of streams.
              > > >
              > > >
              > > > Can you say some more about the way you tested performance against
              > > 'corelib'
              > > > (presumably as3corelib .92.1)? Apart from purely size, I'm interested in
              > > the
              > > > characteristics of the JSON structures you used (e.g. depth of nesting,
              > > > ratio of objects to arrays, object sizes, whitespace / density, etc.).
              > > >
              > > > --
              > > > Martin Cooper
              > > >
              > > >
              > > > you can find it at:
              > > > > http://www.waynemike.co.uk/jswoof
              > > > >
              > > > >
              > > > >
              > > > >
              > > > >
              > > > > ------------------------------------
              > > > >
              > > > > Yahoo! Groups Links
              > > > >
              > > > >
              > > > >
              > > > >
              > > >
              > > >
              > > > [Non-text portions of this message have been removed]
              > > >
              > >
              > >
              > >
              > >
              > > ------------------------------------
              > >
              > > Yahoo! Groups Links
              > >
              > >
              > >
              > >
              >
              >
              > [Non-text portions of this message have been removed]
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.