11:34 p.m.
Optimize marshalling of return values
-------------------------------------
Key: JGRP-284
URL: http://jira.jboss.com/jira/browse/JGRP-284
Project: JGroups
Issue Type: Task
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
I was doing some CPU profiling of JBoss HttpSession replication and
noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
time. Thought that was a bit odd, given that all the RPC calls in JBoss
Cache are to void methods.
Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
an ObjectOutputStream gets created, and then
ObjectOutputStream.writeObject(null) gets called. That method does a
fair amount of stuff before ultimately writing a byte to the stream. On
the other side, an ObjectInputStream is created and readObject() also
jumps through quite a few hoops just to read that byte and return null.
Since in HEAD you're now writing an initial byte to the stream to signal
Streamable or not, perhaps having a 3rd value to signal null would make
sense. Lets you skip the whole initiation of the
ObjectInput/OutputStream as well as the overhead I described.
Brian Stansberry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:34 p.m.
New subject: [JBoss JIRA] Commented: (JGRP-284) Optimize marshalling of return values
[ http://jira.jboss.com/jira/browse/JGRP-284?page=comments#action_12342018 ]
Bela Ban commented on JGRP-284:
-------------------------------
I'll look into it. While we're at it, I noticed JBoss clustering is
missing something: we use an external Marshaller (if configured) to
#1 Marshal requests at the caller
#2 Unmarshall requests at the receiver(s)
BUT we don't use the Marshaller implementation to
#3 Marshal return values into byte[] buffers at the receiver(s) and
#4 Unmarshal the return value at the sender
So I'm going to
- use the configured Marshaller to do #3 and #4
- if there is no Marshaller set, I'll use JGroups'
Util.objectTo/FromByteBuffer, which I'll optimize too
Optimize marshalling of return values
-------------------------------------
Key: JGRP-284
URL: http://jira.jboss.com/jira/browse/JGRP-284
Project: JGroups
Issue Type: Task
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
I was doing some CPU profiling of JBoss HttpSession replication and
noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
time. Thought that was a bit odd, given that all the RPC calls in JBoss
Cache are to void methods.
Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
an ObjectOutputStream gets created, and then
ObjectOutputStream.writeObject(null) gets called. That method does a
fair amount of stuff before ultimately writing a byte to the stream. On
the other side, an ObjectInputStream is created and readObject() also
jumps through quite a few hoops just to read that byte and return null.
Since in HEAD you're now writing an initial byte to the stream to signal
Streamable or not, perhaps having a 3rd value to signal null would make
sense. Lets you skip the whole initiation of the
ObjectInput/OutputStream as well as the overhead I described.
Brian Stansberry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:52 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-284) Optimize marshalling of return values
[ http://jira.jboss.com/jira/browse/JGRP-284?page=comments#action_12342020 ]
Bela Ban commented on JGRP-284:
-------------------------------
First part is donw - we now use the Marshaller (when set). This required moving
unmarshalling of the return value from GroupRequest (where it didn't really belong) to
RequestCorrelator
Optimize marshalling of return values
-------------------------------------
Key: JGRP-284
URL: http://jira.jboss.com/jira/browse/JGRP-284
Project: JGroups
Issue Type: Task
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
I was doing some CPU profiling of JBoss HttpSession replication and
noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
time. Thought that was a bit odd, given that all the RPC calls in JBoss
Cache are to void methods.
Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
an ObjectOutputStream gets created, and then
ObjectOutputStream.writeObject(null) gets called. That method does a
fair amount of stuff before ultimately writing a byte to the stream. On
the other side, an ObjectInputStream is created and readObject() also
jumps through quite a few hoops just to read that byte and return null.
Since in HEAD you're now writing an initial byte to the stream to signal
Streamable or not, perhaps having a 3rd value to signal null would make
sense. Lets you skip the whole initiation of the
ObjectInput/OutputStream as well as the overhead I described.
Brian Stansberry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:20 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-284) Optimize marshalling of return values
[ http://jira.jboss.com/jira/browse/JGRP-284?page=comments#action_12342036 ]
Bela Ban commented on JGRP-284:
-------------------------------
Results for non-optimized versus optimized values:
Non-optimized (ObjectOutputStream.writeObject()):
-----------------------------------------------------------------------
obj=true, obj2=true (type=java.lang.Boolean, length=48 bytes)
obj=false, obj2=false (type=java.lang.Boolean, length=48 bytes)
obj=22, obj2=22 (type=java.lang.Byte, length=76 bytes)
obj=2, obj2=2 (type=java.lang.Byte, length=76 bytes)
obj=5, obj2=5 (type=java.lang.Character, length=51 bytes)
obj=3.14, obj2=3.14 (type=java.lang.Double, length=85 bytes)
obj=352.3, obj2=352.3 (type=java.lang.Float, length=80 bytes)
obj=100, obj2=100 (type=java.lang.Integer, length=82 bytes)
obj=322649, obj2=322649 (type=java.lang.Long, length=83 bytes)
obj=22, obj2=22 (type=java.lang.Short, length=78 bytes)
obj=Bela Ban, obj2=Bela Ban (type=java.lang.String, length=16 bytes)
Optimized:
--------------
bj=true, obj2=true (type=java.lang.Boolean, length=2 bytes)
obj=false, obj2=false (type=java.lang.Boolean, length=2 bytes)
obj=22, obj2=22 (type=java.lang.Byte, length=2 bytes)
obj=2, obj2=2 (type=java.lang.Byte, length=2 bytes)
obj=5, obj2=5 (type=java.lang.Character, length=3 bytes)
obj=3.14, obj2=3.14 (type=java.lang.Double, length=9 bytes)
obj=352.3, obj2=352.3 (type=java.lang.Float, length=5 bytes)
obj=100, obj2=100 (type=java.lang.Integer, length=5 bytes)
obj=322649, obj2=322649 (type=java.lang.Long, length=9 bytes)
obj=22, obj2=22 (type=java.lang.Short, length=3 bytes)
obj=Bela Ban, obj2=Bela Ban (type=java.lang.String, length=11 bytes)
Optimize marshalling of return values
-------------------------------------
Key: JGRP-284
URL: http://jira.jboss.com/jira/browse/JGRP-284
Project: JGroups
Issue Type: Task
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
I was doing some CPU profiling of JBoss HttpSession replication and
noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
time. Thought that was a bit odd, given that all the RPC calls in JBoss
Cache are to void methods.
Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
an ObjectOutputStream gets created, and then
ObjectOutputStream.writeObject(null) gets called. That method does a
fair amount of stuff before ultimately writing a byte to the stream. On
the other side, an ObjectInputStream is created and readObject() also
jumps through quite a few hoops just to read that byte and return null.
Since in HEAD you're now writing an initial byte to the stream to signal
Streamable or not, perhaps having a 3rd value to signal null would make
sense. Lets you skip the whole initiation of the
ObjectInput/OutputStream as well as the overhead I described.
Brian Stansberry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:16 a.m.
New subject: [JBoss JIRA] Resolved: (JGRP-284) Optimize marshalling of return values
[ http://jira.jboss.com/jira/browse/JGRP-284?page=all ]
Bela Ban resolved JGRP-284.
---------------------------
Resolution: Done
unit tests pass
Optimize marshalling of return values
-------------------------------------
Key: JGRP-284
URL: http://jira.jboss.com/jira/browse/JGRP-284
Project: JGroups
Issue Type: Task
Affects Versions: 2.3 SP1
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.4
I was doing some CPU profiling of JBoss HttpSession replication and
noticed that GroupRequest.receiveResponse() took ~ 5% of the total CPU
time. Thought that was a bit odd, given that all the RPC calls in JBoss
Cache are to void methods.
Had a look at Util.objectTo/FromByteBuffer, and if the response is null,
an ObjectOutputStream gets created, and then
ObjectOutputStream.writeObject(null) gets called. That method does a
fair amount of stuff before ultimately writing a byte to the stream. On
the other side, an ObjectInputStream is created and readObject() also
jumps through quite a few hoops just to read that byte and return null.
Since in HEAD you're now writing an initial byte to the stream to signal
Streamable or not, perhaps having a 3rd value to signal null would make
sense. Lets you skip the whole initiation of the
ObjectInput/OutputStream as well as the overhead I described.
Brian Stansberry
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7286
days inactive
7286
days old
4 comments
1 participants
participants (1)
-
Bela Ban (JIRA)