[irvingd]

I'm doing some tests and using Object[] loops instead of Array.getInstance navigation is being much faster.

Unfortunately later I will have to write on array persister for each primitive value. But that's okay. Then I realized regular ObjectOutputStream and ObjectInputStream does the same way.


Clebert

Cool - sounds great!
Do you still want any help with this? I've probably got some spare time over the next couple of weeks - so could probably help out if you want?

Give me a shout and let me know...

Cheers,

Dave

[clebert.suconic]

I already commited the changes for arrays. The package is not on labs yet but it's on CVS already.

I improved the way arrays are serialized but there still some space for improvement.

I'm using auto-boxing for every final field, and I'm going to change that.


I'm considering to create a container class for every final field and use proper reflection operations for each final field instead of converting them to Objects. (java.lang.Number).


If you can think of a design for this, it would be a great contribution.

Take a look on the testcases, and also take a look on the package called persisters, and methods that I called writeMySelf. These places is where the current auto-boxing are happening.


Clebert

[clebert.suconic]

We just created a forum for JBossSerialization.

So, I'm moving this whole thread to that forum.

[clebert.suconic]

I have uploaded the new jar into labs.

If you could test it please.

[prashantpatel]

Hi,

I have been tried jboss serialization and compared results with Java5 and jdk1.4.2_08 and we found that Jboss serialization the slowest. The following is the test data. The need to serialize is because we plan to write the objects to file, hence we large SQL result set and the same objects can be used for pagination.

Customer - which contains?
id (Long)
first name (String)
last name (String)
gender phone number (Integer)
status (Integer)
List (10 policy objects)
Address (address line 1, 2, 3 as strings and 50 address
history same properties as Address address line 1 2 3)
List (50 customer history changes made to customer details)
Policy (which is contained in customer)
id (Long)
List (100 claim objects)
Claim (which is contained in policy)
id (Long)
amount (Double)
claimType (Integer)

Of this object structure we created 100 customers and 50 customers
In a ArrayList and tested writing and reading of 100 and 50 customer
Lists Following is the results when we ran Jprofiler on the code.

No of Customer | Library | time to write | time to read |
100 | J2SE 1.4.2_08 | 3,312 Ms | 3,045 Ms |
100 | Java 5 (best) | 1,941 Ms | 1,388 Ms |
100 | Jboss Serialization |out of memory exp |
------------------------------------------------------------------------------------
50 | J2SE 1.4.2_08 | 728 Ms | 557 Ms |
50 | Java 5 (best) | 362 Ms | 315 Ms |
50 | Jboss Serialization | 941 Ms | 1,209 Ms |

Hope this data help.

[starksm64]

We need the test program itself. Post it to a jira issue in:
http://jira.jboss.com/jira/browse/JBSER

[prashantpatel]

http://jira.jboss.com/jira/browse/JBSER-36

[clebert.suconic]

I have created a test package based in your post, and I got these results:


test-100-jboss-serialization
Time to write = 1191
Time to read = 1663

test-100-JavaSerialization-1.5
Time to write = 1652
Time to read = 831

test-50-JBoss
Time to write = 351
Time to read = 320

test-50-Java
Time to write = 281
Time to read = 270


This is using CVS, which is a newer version than the one I posted into labs. (I'm about to create a new version)

I will make some optimizations based on this test.

I'm assuming I can make your tests as part on CVS as a contribution. (I would keep the author tags of course).

[clebert.suconic]

For test-100-jboss-serialization I had to increase memory in order to pass the memory error. I'll research based on that.

[clebert.suconic]

Just one correction:


The testcase I had was using lots of strings. I have made them unique, and the test now is a little bit more reliable:

test-100-jboss-serialization
Time to write = 1552
Time to read = 1462

test-100-JavaSerialization-1.5
Time to write = 1743
Time to read = 1021

test-50-JBoss
Time to write = 290
Time to read = 351

test-50-Java
Time to write with JBS = 310
Time to read with JBS = 251

[prashantpatel]

I'm assuming I can make your tests as part on CVS as a contribution. (I would keep the author tags of course).

Yes offcourse you can make it a part of the contribution. As soon as you release a new version i will run a test on that.

[patrick145]

I have found that on Solaris 10, Java serialization performance exceeds that of JBoss serialization for single-threaded applications across a variety of object types.

However, in multi-threaded applications I have found the opposite to be true. It would seem that Java serialization has some sort of synchronization bottleneck in something called:

java.lang.Ref.ReferenceQueue$Lock

For highly threaded applications, JBoss performance and scalability greatly exceeded that of plain old Java Serialization.

TEST #Runs Threads BufferSize File System Serializer Size X/s
io 10000 1 32768 ufs Java 21474 142.6
io 10000 2 32768 ufs Java 21474 199.7
io 10000 3 32768 ufs Java 21474 208
io 10000 4 32768 ufs Java 21474 199.7
io 10000 1 32768 swap Java 21474 156.1
io 10000 2 32768 swap Java 21474 203.8
io 10000 3 32768 swap Java 21474 216.9
io 10000 4 32768 swap Java 21474 208

io 10000 1 32768 swap Jboss 25567 116.1
io 10000 2 32768 swap Jboss 25567 249.6
io 10000 3 32768 swap Jboss 25567 368.3
io 10000 4 32768 swap Jboss 25567 474.9
io 10000 8 32768 swap Jboss 25567 828.9
io 10000 12 32768 swap Jboss 25567 986.5
io 10000 16 32768 swap Jboss 25567 1095.9

For larger sample sizes the difference between Java and JBoss diverged. So, I think the answer to the "which is faster?" question is correctly answered by the age-old response "It depends."

If your application is highly threaded and needs to scale, JBoss is likely for you. If single threaded serialization is fine, Java serialization may be for you.

Of course, the landscape is likely to change again in Java 1.6 and 1.7. However, until WebSphere supports this version of the JDK, it is not relevant for my situation.

- Pat