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

Re: [json] Universal Binary JSON Specification

Expand Messages
  • Tatu Saloranta
    Btw, forgot to add: On Wed, Sep 21, 2011 at 6:15 AM, rkalla123 wrote: ... It would be great if you could contribute this to jvm-serialziers,
    Message 1 of 76 , Sep 21, 2011
    View Source
    • 0 Attachment
      Btw, forgot to add:

      On Wed, Sep 21, 2011 at 6:15 AM, rkalla123 <rkalla@...> wrote:
      ...
      > Using the test-data from the popular JVM-Serializer Benchmark project (https://github.com/eishay/jvm-serializers/wiki) in Java, I show a 28% reduction in file size along with a 73% faster deserialization step as compared to Jackson's ObjectMapper.

      It would be great if you could contribute this to jvm-serialziers, I
      can help in getting it merged.

      > NOTE: Jackson is currently the fastest JSON parsing library in Java, however I believe there are ways to make the ObjectMapper run faster i just haven't tuned it yet so 73% is likely not representative of final numbers.
      >
      > My goals are to gun for (on average) a 30% reduction in file size and 50% faster serialization/deserialization processing.
      >
      > For what it is worth, I *expect* serialization/deserialization to run on par with Java manual encoding/decoding which is labeled "java-M" in the JVM Serialization Benchmark results (3rd fastest).

      I actually suspect you are wrong there -- since you require
      length-prefixing, writing is going to be slower, at least for longer
      strings. :-)

      But would be happy to be proven wrong.

      -+ Tatu +-
    • Tatu Saloranta
      ... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-
      Message 76 of 76 , Feb 20, 2012
      View Source
      • 0 Attachment
        On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
        > Stephan,
        >
        > No problem; your feedback are still very applicable and much appreciated.
        >
        > The additional view-point on the signed/unsigned issue was exactly what I was hoping for. My primary goal has always been simplicity and I know at least from the Java world, going with unsigned values would have made the impl distinctly *not* simple (and an annoying API).
        >
        > So I am glad to get some validation there that I am not alienating every other language at the cost of Java.

        For what it is worth, I also consider support for only signed values a
        good thing.

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