Re: Universal Binary JSON Specification
I'd love to get this into jvm-serializers; I have been utilizing the same test data (MediaContent) and models for testing to try and get relatable benchmark data.
The code ends up looking a lot like the Java Manual code, maybe I can hack something together (new class) and send it to you to drop in to your working install and see if that would work?
Thanks for the assist with this.
--- In firstname.lastname@example.org, Tatu Saloranta <tsaloranta@...> wrote:
> 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 +-
- On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,For what it is worth, I also consider support for only signed values a
> 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.
-+ Tatu +-