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

Re: [json] JSWOOF - New JSON Parser For FLEX.

Expand Messages
  • 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 1 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 2 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 3 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 4 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.