[infinispan-dev] Marshalling/unmarshalling known type

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Marshalling/unmarshalling known type

Radim Vansa
Hi,

I've noticed that sometimes we marshall objects just using
output.writeObject() even though we know the target type - one example
for all is CommandInvocationId. That's somewhat suboptimal, as we know
that there won't be any CommandInvocationIdEx, so we could spare the
externalizer lookup and few bytes for object identifier.

Is there any better way than

new CommandInvocationId.Externalizer().writeObject(output,
commandInvocationId)?

Should we use this ^? I guess that object allocation will be eliminated
here easily.

Radim

--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Marshalling/unmarshalling known type

Pedro Ruivo-2
Hi,

I've noticed the same when I refactor the commands marshalling.

I thought about creating a MarshallUtil.writeObjectWithExternalizer(T
obj, Externalizer<T> ext) to handle this cases but it was outside the
scope of that JIRA.

In the end, most of the externalizers are stateless and it can be a
Singleton and the allocation can be removed. +1 to create a JIRA to
improve this cases.

Pedro


On 04/25/2016 01:36 PM, Radim Vansa wrote:

> Hi,
>
> I've noticed that sometimes we marshall objects just using
> output.writeObject() even though we know the target type - one example
> for all is CommandInvocationId. That's somewhat suboptimal, as we know
> that there won't be any CommandInvocationIdEx, so we could spare the
> externalizer lookup and few bytes for object identifier.
>
> Is there any better way than
>
> new CommandInvocationId.Externalizer().writeObject(output,
> commandInvocationId)?
>
> Should we use this ^? I guess that object allocation will be eliminated
> here easily.
>
> Radim
>
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Marshalling/unmarshalling known type

Sanne Grinovero-3
+1

I do similar tricks in externalizing some metadata for Lucene: some
custom Externalizers expose a static helper method so others from the
same package can invoke it directly.

On 25 April 2016 at 15:25, Pedro Ruivo <[hidden email]> wrote:

> Hi,
>
> I've noticed the same when I refactor the commands marshalling.
>
> I thought about creating a MarshallUtil.writeObjectWithExternalizer(T
> obj, Externalizer<T> ext) to handle this cases but it was outside the
> scope of that JIRA.
>
> In the end, most of the externalizers are stateless and it can be a
> Singleton and the allocation can be removed. +1 to create a JIRA to
> improve this cases.
>
> Pedro
>
>
> On 04/25/2016 01:36 PM, Radim Vansa wrote:
>> Hi,
>>
>> I've noticed that sometimes we marshall objects just using
>> output.writeObject() even though we know the target type - one example
>> for all is CommandInvocationId. That's somewhat suboptimal, as we know
>> that there won't be any CommandInvocationIdEx, so we could spare the
>> externalizer lookup and few bytes for object identifier.
>>
>> Is there any better way than
>>
>> new CommandInvocationId.Externalizer().writeObject(output,
>> commandInvocationId)?
>>
>> Should we use this ^? I guess that object allocation will be eliminated
>> here easily.
>>
>> Radim
>>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev