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

Re: [json] libjson 7.0 new features

Expand Messages
  • Tatu Saloranta
    Interesting. One thing I noticed from the project page is that there are big claims on performance, but it seems to lack links to actual measurements? I was
    Message 1 of 9 , Feb 3 11:12 AM
    • 0 Attachment
      Interesting. One thing I noticed from the project page is that there
      are big claims on performance, but it seems to lack links to actual
      measurements? I was wondering if you can add links, so it is possible
      to see actual performance numbers, figure out relative importance of
      performance and so on
      I have noticed that at least half of all JSON projects claim to be
      faster than anyone else, so measurements could also clear up the
      situation and keep everyone honest.

      -+ Tatu +-

      On Thu, Feb 3, 2011 at 5:54 AM, jonathan wallace <ninja9578@...> wrote:
      > Hello all,
      >
      > I just wanted to mention that a while ago I changed the name from libJSON to libjson, would you mind reflecting that on json.org?
      >
      > I added a ton of new stuff in this upgrade, most significantly, streaming ability.  I got a bunch of requests for the ability to take a stream (like from the internet) and parse it as it comes in.  Since it may be partial JSON, or multiple JSON objects at a time, the stream will check each time something gets added to it, and call a callback with the new node each time one is completed.  This should make life a lot easier for those streaming JSON from websources.
      >
      > I also added the option to turn off all libjson extensions such as comments, hexidecimal support... so that only 100% compliant JSON is considered valid.
      >
      > I exposed an interface to use libjson's base64 encoder and decoder since a few people asked if they could use it.
      >
      > There is a new makefile with lots more options, including an install script.  (Thanks to Bernhard Fluehmann)
      >
      > There were several other changes too, you can see them all in the changelog in the documentation if you wish.
      > http://sourceforge.net/projects/libjson/
      >
      > Jon
      >
      >
      >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • David Graham
      If you d prefer a really slow JSON parser, check out https://github.com/dgraham/json-stream. It s about 20x slower than the Ruby json gem, but it s quite
      Message 2 of 9 , Feb 3 11:36 AM
      • 0 Attachment
        If you'd prefer a really slow JSON parser, check out
        https://github.com/dgraham/json-stream. It's about 20x slower than the Ruby
        json gem, but it's quite handy if you need to parse a single huge JSON
        document in constant memory space.

        Enjoy!

        David


        On Thu, Feb 3, 2011 at 12:12 PM, Tatu Saloranta <tsaloranta@...>wrote:

        >
        >
        > Interesting. One thing I noticed from the project page is that there
        > are big claims on performance, but it seems to lack links to actual
        > measurements? I was wondering if you can add links, so it is possible
        > to see actual performance numbers, figure out relative importance of
        > performance and so on
        > I have noticed that at least half of all JSON projects claim to be
        > faster than anyone else, so measurements could also clear up the
        > situation and keep everyone honest.
        >
        > -+ Tatu +-
        >
        > On Thu, Feb 3, 2011 at 5:54 AM, jonathan wallace <ninja9578@...<ninja9578%40yahoo.com>>
        > wrote:
        > > Hello all,
        > >
        > > I just wanted to mention that a while ago I changed the name from libJSON
        > to libjson, would you mind reflecting that on json.org?
        > >
        > > I added a ton of new stuff in this upgrade, most significantly, streaming
        > ability. I got a bunch of requests for the ability to take a stream (like
        > from the internet) and parse it as it comes in. Since it may be partial
        > JSON, or multiple JSON objects at a time, the stream will check each time
        > something gets added to it, and call a callback with the new node each time
        > one is completed. This should make life a lot easier for those streaming
        > JSON from websources.
        > >
        > > I also added the option to turn off all libjson extensions such as
        > comments, hexidecimal support... so that only 100% compliant JSON is
        > considered valid.
        > >
        > > I exposed an interface to use libjson's base64 encoder and decoder since
        > a few people asked if they could use it.
        > >
        > > There is a new makefile with lots more options, including an install
        > script. (Thanks to Bernhard Fluehmann)
        > >
        > > There were several other changes too, you can see them all in the
        > changelog in the documentation if you wish.
        > > http://sourceforge.net/projects/libjson/
        > >
        > > Jon
        > >
        > >
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        >
        >


        [Non-text portions of this message have been removed]
      • Gregg Irwin
        TS I have noticed that at least half of all JSON projects claim to be TS faster than anyone else, so measurements could also clear up the TS situation and
        Message 3 of 9 , Feb 3 12:00 PM
        • 0 Attachment
          TS> I have noticed that at least half of all JSON projects claim to be
          TS> faster than anyone else, so measurements could also clear up the
          TS> situation and keep everyone honest.

          A standard JSON benchmark perhaps?

          --Gregg
        • Tatu Saloranta
          ... Yes, one would be very useful. I know there are couple for Java (general purpose ones that can also use JSON; and specific ones), but haven t seen many for
          Message 4 of 9 , Feb 3 4:03 PM
          • 0 Attachment
            On Thu, Feb 3, 2011 at 12:00 PM, Gregg Irwin <gregg.irwin@...> wrote:
            > TS> I have noticed that at least half of all JSON projects claim to be
            > TS> faster than anyone else, so measurements could also clear up the
            > TS> situation and keep everyone honest.
            >
            > A standard JSON benchmark perhaps?

            Yes, one would be very useful. I know there are couple for Java
            (general purpose ones that can also use JSON; and specific ones), but
            haven't seen many for other platforms, or comparing between platforms.

            -+ Tatu +-
          • jonathan wallace
            If there is a standard JSON benchmark that would be nice. I ve only compared it to wxJSON, cJSON, and a few others. People have always been impressed by the
            Message 5 of 9 , Feb 7 6:11 AM
            • 0 Attachment
              If there is a standard JSON benchmark that would be nice.


              I've only compared it to wxJSON, cJSON, and a few others.

              "People have always been impressed by the power of our example, not the example of our power." - William Jefferson Clinton


              From: Tatu Saloranta <tsaloranta@...>
              To: json@yahoogroups.com
              Cc:
              Sent: Thursday, February 3, 2011 7:03 PM
              Subject: Re: Re[2]: [json] libjson 7.0 new features



              On Thu, Feb 3, 2011 at 12:00 PM, Gregg Irwin <gregg.irwin@...> wrote:
              > TS> I have noticed that at least half of all JSON projects claim to be
              > TS> faster than anyone else, so measurements could also clear up the
              > TS> situation and keep everyone honest.
              >
              > A standard JSON benchmark perhaps?

              Yes, one would be very useful. I know there are couple for Java
              (general purpose ones that can also use JSON; and specific ones), but
              haven't seen many for other platforms, or comparing between platforms.

              -+ Tatu +-






              [Non-text portions of this message have been removed]
            • Tatu Saloranta
              ... I suspect many users would like to see comparisons. Maybe blog about it or such (and include test code), or send a link if already published? I don t doubt
              Message 6 of 9 , Feb 7 2:09 PM
              • 0 Attachment
                On Mon, Feb 7, 2011 at 6:11 AM, jonathan wallace <ninja9578@...> wrote:
                > If there is a standard JSON benchmark that would be nice.
                >
                >
                > I've only compared it to wxJSON, cJSON, and a few others.

                I suspect many users would like to see comparisons. Maybe blog about
                it or such (and include test code), or send a link if already
                published?

                I don't doubt at all that there are differences, given difference
                skill & experience levels of implementors (and the common "simplest
                must be fasters" fallacy wrt performance). It's just hard to find out
                real numbers when project home pages do not show measurements, just
                state results.

                -+ Tatu +-
              • Jonathan Wallace
                Well there is a benchmark included in the source, but it s mostly for my own purposes of comparing upgrade versions against the previous version. I think ill
                Message 7 of 9 , Feb 8 10:05 AM
                • 0 Attachment
                  Well there is a benchmark included in the source, but it's mostly for my own purposes of comparing upgrade versions against the previous version. I think ill come up a set of common json tasks and implement them in a few libraries or ask the library maintained to do it to be sure it's done right.

                  Sent from my iPhone

                  On Feb 7, 2011, at 17:09, Tatu Saloranta <tsaloranta@...> wrote:

                  > On Mon, Feb 7, 2011 at 6:11 AM, jonathan wallace <ninja9578@...> wrote:
                  > > If there is a standard JSON benchmark that would be nice.
                  > >
                  > >
                  > > I've only compared it to wxJSON, cJSON, and a few others.
                  >
                  > I suspect many users would like to see comparisons. Maybe blog about
                  > it or such (and include test code), or send a link if already
                  > published?
                  >
                  > I don't doubt at all that there are differences, given difference
                  > skill & experience levels of implementors (and the common "simplest
                  > must be fasters" fallacy wrt performance). It's just hard to find out
                  > real numbers when project home pages do not show measurements, just
                  > state results.
                  >
                  > -+ Tatu +-
                  >


                  [Non-text portions of this message have been removed]
                • Tatu Saloranta
                  ... That would be very useful! I know it might be bit of work, given differing APIs and all.. but then again, it should be beneficial for authors of other
                  Message 8 of 9 , Feb 8 11:20 AM
                  • 0 Attachment
                    On Tue, Feb 8, 2011 at 10:05 AM, Jonathan Wallace <ninja9578@...> wrote:
                    > Well there is a benchmark included in the source, but it's mostly for my own purposes of comparing upgrade versions against the previous version.  I think ill come up a set of common json tasks and implement them in a few libraries or ask the library maintained to do it to be sure it's done right.

                    That would be very useful! I know it might be bit of work, given
                    differing APIs and all.. but then again, it should be beneficial for
                    authors of other packages to work on being able to run similar tests.
                    So it should be possible to get things bootstrapped. This is how
                    "jvm-serializers" (https://github.com/eishay/jvm-serializers) for Java
                    serialization libraries started, and seems to work quite well.

                    -+ Tatu +-
                  Your message has been successfully submitted and would be delivered to recipients shortly.