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

Re: A new java JSON API + Up to date benchmarks and test for most existing Json API.

Expand Messages
  • marsdenjw
    Hello Uriel, I think benchmarking is a great way to compare the frameworks (and motivate lazy developers like myself who never finish anything). I run the
    Message 1 of 18 , May 16, 2011
    • 0 Attachment
      Hello Uriel,

      I think benchmarking is a great way to compare the frameworks (and motivate lazy developers like myself who never finish anything). I run the JSONiJ failed tests on the latest release and I get one fail and another which is open for discussion.

      Unit test: http://pastebin.com/SjuzXxTb
      Output: http://pastebin.com/4GYbHwKq

      Specifically, it passes,

      1. Support Empty Object
      2. Support simple Object float value
      3. Support lowcase float value
      4. Array of empty Object

      Its questionable if I pass
      1. Bigint number support - I can see why this is an issue. I put it in that notation on purpose, but if its a key to something then it will break it.
      Input: { "v":123456789123456789123456789}
      Output: {"v":1.2345678912345679E26}

      I totally fail
      1. Double precision floating point

      I will see if I can get your harness up and running and see if I can see why. At the moment i am working so it will have to wait.

      John

      --- In json@yahoogroups.com, "marsdenjw" <j.w.marsden@...> wrote:
      >
      > Wow, JSONiJ sucks.
      >
      > Regards,
      >
      > John (Developer, JSONiJ)
      >
      > --- In json@yahoogroups.com, "uriel.chemouni" <uriel.chemouni@> wrote:
      > >
      > > Hi
      > >
      > > I have recently published my Json API.
      > >
      > > Features test:
      > > http://code.google.com/p/json-smart/wiki/FeaturesTests
      > >
      > > Benches test:
      > > http://code.google.com/p/json-smart/wiki/Benchmark
      > >
      > > Project home;
      > > http://code.google.com/p/json-smart
      > >
      > > Don't hesitate to send me your feedback.
      > >
      >
    • uriel.chemouni
      This table is more than 150 000 000 lines long, switching to text will dramatically impact performances, and disk usage.
      Message 2 of 18 , May 17, 2011
      • 0 Attachment
        This table is more than 150 000 000 lines long, switching to text will dramatically impact performances, and disk usage.

        --- In json@yahoogroups.com, Stephan Beal <sgbeal@...> wrote:
        >
        > >
        > > By default Json-smart only using strict Json data, I only use compact json
        > > to fill my Mysql varchar(255) collumns.
        > >
        >
        > If you'll make the columns of type TEXT, the stored JSON can have any size.
        > i use this in a wiki back-end which stores pages in JSON form.
        >
        > --
        > ----- stephan beal
        > http://wanderinghorse.net/home/stephan/
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • uriel.chemouni
        Great, JSONiJ 0.2.3.9 can now validate all my tests. It deserves an update results in json-smart. Good job jhon.
        Message 3 of 18 , May 20, 2011
        • 0 Attachment
          Great, JSONiJ 0.2.3.9 can now validate all my tests.

          It deserves an update results in json-smart.

          Good job jhon.

          --- In json@yahoogroups.com, "marsdenjw" <j.w.marsden@...> wrote:
          >
          > Hello Uriel,
          >
          > I think benchmarking is a great way to compare the frameworks (and motivate lazy developers like myself who never finish anything). I run the JSONiJ failed tests on the latest release and I get one fail and another which is open for discussion.
          >
          > Unit test: http://pastebin.com/SjuzXxTb
          > Output: http://pastebin.com/4GYbHwKq
          >
          > Specifically, it passes,
          >
          > 1. Support Empty Object
          > 2. Support simple Object float value
          > 3. Support lowcase float value
          > 4. Array of empty Object
          >
          > Its questionable if I pass
          > 1. Bigint number support - I can see why this is an issue. I put it in that notation on purpose, but if its a key to something then it will break it.
          > Input: { "v":123456789123456789123456789}
          > Output: {"v":1.2345678912345679E26}
          >
          > I totally fail
          > 1. Double precision floating point
          >
          > I will see if I can get your harness up and running and see if I can see why. At the moment i am working so it will have to wait.
          >
          > John
          >
          > --- In json@yahoogroups.com, "marsdenjw" <j.w.marsden@> wrote:
          > >
          > > Wow, JSONiJ sucks.
          > >
          > > Regards,
          > >
          > > John (Developer, JSONiJ)
          > >
          > > --- In json@yahoogroups.com, "uriel.chemouni" <uriel.chemouni@> wrote:
          > > >
          > > > Hi
          > > >
          > > > I have recently published my Json API.
          > > >
          > > > Features test:
          > > > http://code.google.com/p/json-smart/wiki/FeaturesTests
          > > >
          > > > Benches test:
          > > > http://code.google.com/p/json-smart/wiki/Benchmark
          > > >
          > > > Project home;
          > > > http://code.google.com/p/json-smart
          > > >
          > > > Don't hesitate to send me your feedback.
          > > >
          > >
          >
        • marsdenjw
          No problem - as I said. I think its a good way to compare frameworks. I am working on making it a little bit quicker now. It was built to parse input streams
          Message 4 of 18 , May 21, 2011
          • 0 Attachment
            No problem - as I said. I think its a good way to compare frameworks.

            I am working on making it a little bit quicker now. It was built to parse input streams directly and not strings. The String current string parse is fine for small strings, but when they get large like your tests its a bit silly.

            https://bitbucket.org/openecho/jsonij/src/653c6b5f85c8/src/main/java/jsonij/json/JSONParser.java#cl-90

            It pushes the string contents into a byte buffer and then reads the bytes. Its not too much work to make another version of the reader itself to work directly on the input string.

            John

            --- In json@yahoogroups.com, "uriel.chemouni" <uriel.chemouni@...> wrote:
            >
            > Great, JSONiJ 0.2.3.9 can now validate all my tests.
            >
            > It deserves an update results in json-smart.
            >
            > Good job jhon.
            >
            > --- In json@yahoogroups.com, "marsdenjw" <j.w.marsden@> wrote:
            > >
            > > Hello Uriel,
            > >
            > > I think benchmarking is a great way to compare the frameworks (and motivate lazy developers like myself who never finish anything). I run the JSONiJ failed tests on the latest release and I get one fail and another which is open for discussion.
            > >
            > > Unit test: http://pastebin.com/SjuzXxTb
            > > Output: http://pastebin.com/4GYbHwKq
            > >
            > > Specifically, it passes,
            > >
            > > 1. Support Empty Object
            > > 2. Support simple Object float value
            > > 3. Support lowcase float value
            > > 4. Array of empty Object
            > >
            > > Its questionable if I pass
            > > 1. Bigint number support - I can see why this is an issue. I put it in that notation on purpose, but if its a key to something then it will break it.
            > > Input: { "v":123456789123456789123456789}
            > > Output: {"v":1.2345678912345679E26}
            > >
            > > I totally fail
            > > 1. Double precision floating point
            > >
            > > I will see if I can get your harness up and running and see if I can see why. At the moment i am working so it will have to wait.
            > >
            > > John
            > >
            > > --- In json@yahoogroups.com, "marsdenjw" <j.w.marsden@> wrote:
            > > >
            > > > Wow, JSONiJ sucks.
            > > >
            > > > Regards,
            > > >
            > > > John (Developer, JSONiJ)
            > > >
            > > > --- In json@yahoogroups.com, "uriel.chemouni" <uriel.chemouni@> wrote:
            > > > >
            > > > > Hi
            > > > >
            > > > > I have recently published my Json API.
            > > > >
            > > > > Features test:
            > > > > http://code.google.com/p/json-smart/wiki/FeaturesTests
            > > > >
            > > > > Benches test:
            > > > > http://code.google.com/p/json-smart/wiki/Benchmark
            > > > >
            > > > > Project home;
            > > > > http://code.google.com/p/json-smart
            > > > >
            > > > > Don't hesitate to send me your feedback.
            > > > >
            > > >
            > >
            >
          • Tatu Saloranta
            ... Are these tests also available with source code? Results for Jackson looked odd; as if some assumptions were being made that are not true (assuming
            Message 5 of 18 , May 21, 2011
            • 0 Attachment
              On Sat, May 21, 2011 at 3:47 AM, marsdenjw <j.w.marsden@...> wrote:
              > No problem - as I said. I think its a good way to compare frameworks.

              Are these tests also available with source code? Results for Jackson
              looked odd; as if some assumptions were being made that are not true
              (assuming round-tripping of white space, or specific style of escaping
              characters)

              >
              > I am working on making it a little bit quicker now. It was built to parse input streams directly and not strings. The String current string parse is fine for small strings, but when they get large like your tests its a bit silly.

              I think using String as input does not make much sense -- most
              real-world use cases start with a byte sequence (reading from a file,
              receiving or sending requests), and it is only question of who does
              decoding/encoding necessary. When starting with a String (or Reader)
              it is assumed that parser can not do this, which is true for some
              parsers but not all. And since encoding/decoding between bytes and
              characters is a major factor in performance, this skews results a lot.

              -+ Tatu +-
            • marsdenjw
              Hi Tatu, If that question was addressed to me, then no, I dont have the source. I just made unit tests for each test I was said to fail and went from there
              Message 6 of 18 , May 23, 2011
              • 0 Attachment
                Hi Tatu,

                If that question was addressed to me, then no, I dont have the source. I just made unit tests for each test I was said to fail and went from there (https://bitbucket.org/openecho/jsonij/src/a25fd28c1d77/src/test/java/jsonij/json/SJTest.java). Im not sure how fussy his code is about spaces and differences in valid results...

                I agree totally with the byte sequence comment. Every time I use JSON I am parsing from a HTTP source or I am loading from a file.

                Regards,

                John

                --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
                >
                > On Sat, May 21, 2011 at 3:47 AM, marsdenjw <j.w.marsden@...> wrote:
                > > No problem - as I said. I think its a good way to compare frameworks.
                >
                > Are these tests also available with source code? Results for Jackson
                > looked odd; as if some assumptions were being made that are not true
                > (assuming round-tripping of white space, or specific style of escaping
                > characters)
                >
                > >
                > > I am working on making it a little bit quicker now. It was built to parse input streams directly and not strings. The String current string parse is fine for small strings, but when they get large like your tests its a bit silly.
                >
                > I think using String as input does not make much sense -- most
                > real-world use cases start with a byte sequence (reading from a file,
                > receiving or sending requests), and it is only question of who does
                > decoding/encoding necessary. When starting with a String (or Reader)
                > it is assumed that parser can not do this, which is true for some
                > parsers but not all. And since encoding/decoding between bytes and
                > characters is a major factor in performance, this skews results a lot.
                >
                > -+ Tatu +-
                >
              • Tatu Saloranta
                ... Sorry, it was question to author, and he did actually add a link to wiki. So I was able to figure it out, and submit a patch for jackson test. I hope
                Message 7 of 18 , May 23, 2011
                • 0 Attachment
                  On Mon, May 23, 2011 at 3:49 AM, marsdenjw <j.w.marsden@...> wrote:
                  > Hi Tatu,
                  >
                  > If that question was addressed to me, then no, I dont have the source. I just made unit tests for each test I was said to fail and went from there (https://bitbucket.org/openecho/jsonij/src/a25fd28c1d77/src/test/java/jsonij/json/SJTest.java). Im not sure how fussy his code is about spaces and differences in valid results...

                  Sorry, it was question to author, and he did actually add a link to
                  wiki. So I was able to figure it out, and submit a patch for jackson
                  test. I hope authors of other JSON libs can do the same, so that
                  results reflect actual working of libs.

                  > I agree totally with the byte sequence comment. Every time I use JSON I am parsing from a HTTP source or I am loading from a file.

                  Yeah, that is my experience as well. Maybe this was based on using a
                  framework that does loading and decoding first, just passing JSON
                  contents. Occasionally this is true, when binding data from form
                  parameters or something. But not very often at least for me.

                  -+ Tatu +-
                • uriel.chemouni
                  do not hesitate to submit paths to my benchmark code. The new version display warmed-up JVM result, and display all results as percents. The results are easier
                  Message 8 of 18 , May 23, 2011
                  • 0 Attachment
                    do not hesitate to submit paths to my benchmark code.
                    The new version display warmed-up JVM result, and display all results as percents.
                    The results are easier to read.

                    --- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
                    >
                    > On Mon, May 23, 2011 at 3:49 AM, marsdenjw <j.w.marsden@...> wrote:
                    > > Hi Tatu,
                    > >
                    > > If that question was addressed to me, then no, I dont have the source. I just made unit tests for each test I was said to fail and went from there (https://bitbucket.org/openecho/jsonij/src/a25fd28c1d77/src/test/java/jsonij/json/SJTest.java). Im not sure how fussy his code is about spaces and differences in valid results...
                    >
                    > Sorry, it was question to author, and he did actually add a link to
                    > wiki. So I was able to figure it out, and submit a patch for jackson
                    > test. I hope authors of other JSON libs can do the same, so that
                    > results reflect actual working of libs.
                    >
                    > > I agree totally with the byte sequence comment. Every time I use JSON I am parsing from a HTTP source or I am loading from a file.
                    >
                    > Yeah, that is my experience as well. Maybe this was based on using a
                    > framework that does loading and decoding first, just passing JSON
                    > contents. Occasionally this is true, when binding data from form
                    > parameters or something. But not very often at least for me.
                    >
                    > -+ Tatu +-
                    >
                  • Mark Joseph
                    https://www.p6r.com/articles/2012/01/30/p6r-kmip-toolkit-introduction/ Best, Mark Joseph, Ph.D. President P6R, Inc 408-205-0361 mark@p6r.com Skype:
                    Message 9 of 18 , Feb 1, 2012
                    • 0 Attachment
                      https://www.p6r.com/articles/2012/01/30/p6r-kmip-toolkit-introduction/



                      Best,

                      Mark Joseph, Ph.D.
                      President
                      P6R, Inc
                      408-205-0361
                      mark@...
                      Skype: markjoseph_sc
                      _____



                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.