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

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

Expand Messages
  • 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 1 of 5 , Apr 28, 2009
    • 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 2 of 5 , Apr 29, 2009
      • 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.