10:59 a.m.
Changing the subject, as Adrian will need a reply to his (more
important) question.
I don't think we should go shopping for different marshaller
implementations, especially given other priorities.
I've been keeping an eye on Kryo since a while and it looks very good
indeed, but JBMarshaller is serving us pretty well and I'm loving its
reliability.
If we need more speed in this area, I'd rather see us perform some
very accurate benchmark development and try to understand why Kyro is
faster than JBM (if it really is), and potentially improve JBM.
For example as I've already suggested, it's using an internal
identityMap to detect graphs, and often we might not need that, or
also it would be nice to refactor it to write to an existing byte
stream rather than having it allocate internal buffers, and finally we
might want a "stateless edition" so to get rid of need for pooling of
JBMar instances.
-- Sanne
On 31 January 2014 16:29, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
Not 100% related to what you are asking about but have a look at
this
post and the discussion that "erupted":
http://gridgain.blogspot.ca/2012/12/java-serialization-good-fast-and-fast...
Vladimir
On 1/30/2014, 7:13 AM, Adrian Nistor wrote:
> Hi list!
>
> I've been pondering about re-using the marshalling machinery of
> Infinispan in another project, specifically in ProtoStream, where I'm
> planning to add it as a test scoped dependency so I can create a
> benchmark to compare marshalling performace. I'm basically interested
> in comparing ProtoStream and Infinispan's JBoss Marshalling based
> mechanism. Comparing against plain JBMAR, without using the
> ExternalizerTable and Externalizers introduced by Infinispan is not
> going to get me accurate results.
>
> But how? I see the marshaling is spread across infinispan-commons and
> infinispan-core modules.
>
> Thanks!
> Adrian
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:22 p.m.
Indeed, I'm not looking for a JBMAR replacement, just trying to create a
comparative benchmark between it and Protobuf/ProtoStream.
I'm trying to make an apple to apple comparison by marshalling the same
domain model with both libraries. My (incipient) test currently
indicates a 2x better write perf and 3x better read perf with
ProtoStream but I'm sure it is flawed because I do not have custom JBMAR
externalizers for my entities so I suspect it is basically resorting to
plain old serialization. Was hoping to reuse this part from infinispan
but is seems to be very tied to core.
Need to dig deeper into that awesome jbmar user guide :)
On 01/31/2014 06:59 PM, Sanne Grinovero wrote:
Changing the subject, as Adrian will need a reply to his (more
important) question.
I don't think we should go shopping for different marshaller
implementations, especially given other priorities.
I've been keeping an eye on Kryo since a while and it looks very good
indeed, but JBMarshaller is serving us pretty well and I'm loving its
reliability.
If we need more speed in this area, I'd rather see us perform some
very accurate benchmark development and try to understand why Kyro is
faster than JBM (if it really is), and potentially improve JBM.
For example as I've already suggested, it's using an internal
identityMap to detect graphs, and often we might not need that, or
also it would be nice to refactor it to write to an existing byte
stream rather than having it allocate internal buffers, and finally we
might want a "stateless edition" so to get rid of need for pooling of
JBMar instances.
-- Sanne
On 31 January 2014 16:29, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
> Not 100% related to what you are asking about but have a look at this
> post and the discussion that "erupted":
>
> http://gridgain.blogspot.ca/2012/12/java-serialization-good-fast-and-fast...
>
> Vladimir
> On 1/30/2014, 7:13 AM, Adrian Nistor wrote:
>> Hi list!
>>
>> I've been pondering about re-using the marshalling machinery of
>> Infinispan in another project, specifically in ProtoStream, where I'm
>> planning to add it as a test scoped dependency so I can create a
>> benchmark to compare marshalling performace. I'm basically interested
>> in comparing ProtoStream and Infinispan's JBoss Marshalling based
>> mechanism. Comparing against plain JBMAR, without using the
>> ExternalizerTable and Externalizers introduced by Infinispan is not
>> going to get me accurate results.
>>
>> But how? I see the marshaling is spread across infinispan-commons and
>> infinispan-core modules.
>>
>> Thanks!
>> Adrian
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:42 a.m.
I recently had a very bad experience with Kryo. A JGroups user used Kryo
to marshal data types into byte buffers which he then broadcast around
using JGroups (details in [1]).
Turns out the culprit was Kryo temporarily flipping bits in an already
marshalled buffer passed to JGroups. Of course retransmission would then
cause a corrupted buffer to be sent.
The solution was to copy the buffer which forfeits the advantages of
using Kryo. Not being an expert on Kryo, perhaps this could be done
differently, e.g. by synchronizing around a buffer...
[1] https://issues.jboss.org/browse/JGRP-1718
On 31/01/14 17:59, Sanne Grinovero wrote:
Changing the subject, as Adrian will need a reply to his (more
important) question.
I don't think we should go shopping for different marshaller
implementations, especially given other priorities.
I've been keeping an eye on Kryo since a while and it looks very good
indeed, but JBMarshaller is serving us pretty well and I'm loving its
reliability.
If we need more speed in this area, I'd rather see us perform some
very accurate benchmark development and try to understand why Kyro is
faster than JBM (if it really is), and potentially improve JBM.
For example as I've already suggested, it's using an internal
identityMap to detect graphs, and often we might not need that, or
also it would be nice to refactor it to write to an existing byte
stream rather than having it allocate internal buffers, and finally we
might want a "stateless edition" so to get rid of need for pooling of
JBMar instances.
-- Sanne
On 31 January 2014 16:29, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
> Not 100% related to what you are asking about but have a look at this
> post and the discussion that "erupted":
>
> http://gridgain.blogspot.ca/2012/12/java-serialization-good-fast-and-fast...
>
> Vladimir
> On 1/30/2014, 7:13 AM, Adrian Nistor wrote:
>> Hi list!
>>
>> I've been pondering about re-using the marshalling machinery of
>> Infinispan in another project, specifically in ProtoStream, where I'm
>> planning to add it as a test scoped dependency so I can create a
>> benchmark to compare marshalling performace. I'm basically interested
>> in comparing ProtoStream and Infinispan's JBoss Marshalling based
>> mechanism. Comparing against plain JBMAR, without using the
>> ExternalizerTable and Externalizers introduced by Infinispan is not
>> going to get me accurate results.
>>
>> But how? I see the marshaling is spread across infinispan-commons and
>> infinispan-core modules.
>>
>> Thanks!
>> Adrian
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (http://www.jgroups.org)
3769
days inactive
3771
days old
infinispan-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Adrian Nistor -
Bela Ban -
Sanne Grinovero