Question about thrift serialization performance

[albert guo]

I generated 200000 test objects, and call TSerializer.serialize method to serialize objects. I found that the performance fluctuate very much. Below is the result for each 10000

start serializing with compact protocol

621 millis(0 seconds) for 10000

2925 millis(2 seconds) for 10000

8408 millis(8 seconds) for 10000

12669 millis(12 seconds) for 10000

25556 millis(25 seconds) for 10000

30454 millis(30 seconds) for 10000

33181 millis(33 seconds) for 10000

36601 millis(36 seconds) for 10000

39498 millis(39 seconds) for 10000

26833 millis(26 seconds) for 10000

6483 millis(6 seconds) for 10000

4559 millis(4 seconds) for 10000

2996 millis(2 seconds) for 10000

1886 millis(1 seconds) for 10000

1125 millis(1 seconds) for 10000

837 millis(0 seconds) for 10000

666 millis(0 seconds) for 10000

484 millis(0 seconds) for 10000

307 millis(0 seconds) for 10000

takes 236227 millis (236 seconds) to serialize 200000 objects.

JVM parameter is like below

-Xms512m -Xmx512m -XX:+UseConcMarkSweepGC -server

Anybody has any idea about that?

[Kannan Goundan]

Did you use the existing benchmarking program or did you write your own?

The benchmarking program runs many iterations of the serializer ahead of time ("warm up") before measuring performance.  I believe the primary purpose of this is to let the JIT make optimizations, which is intended to simulate the state-state performance of the serialization libraries in a long-running process.

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-serialization-benchmarking?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Eishay Smith]

Yes Kannan, you're right about the warming up / JIT.

[albert guo]

I write my own. My assumption is if JIT impact my benchmark working, the affect should appear in the beginning of entire process. However, like below demonstrate, the slowness start in the middle of execution. Any idea why?

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

[albert guo]

Maybe I confuse you. The time record I posted below is actually for 200,000 records. I just log its serialization cost each 10,000 records. Will JIT still an issue?

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-serialization-benchmarking?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

[Eishay Smith]

I assume you add up the cost for the 10,000 records. If that's right then you must take in account that your benchmark main thread is not the only thread running in the jvm and the process is not the only one in the OS. The jvm may have background processes (e.g. the GC) which may slow down your running thread, and it makes sense that it would kick in after few seconds of intense object creation. Same goes for background processes in the OS level e.g. swapping processes memory into disk to allow the new growing jvm to claim memory.

That's why the benchmark is taking the fastest run of each block of iteration with the hope that at least one of them will get lucky and won't be context switched while running.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.

[albert guo]

I agree that. So I print out the GC below. Actually it is only parnew gc, and it is fast. The problem is that I can get same running results every time.

975 millis(0 seconds) for 10000

3111 millis(3 seconds) for 10000

8655 millis(8 seconds) for 10000

[GC [ParNew: 178688K->22272K(200960K), 0.0696684 secs] 178688K->43929K(502016K), 0.0697069 secs] [Times: user=0.06 sys=0.02, real=0.06 secs] 

14754 millis(14 seconds) for 10000

20959 millis(20 seconds) for 10000

24037 millis(24 seconds) for 10000

27446 millis(27 seconds) for 10000

29634 millis(29 seconds) for 10000

32394 millis(32 seconds) for 10000

[GC [ParNew: 200960K->21667K(200960K), 0.0323460 secs] 222617K->65106K(502016K), 0.0323801 secs] [Times: user=0.06 sys=0.01, real=0.05 secs] 

10452 millis(10 seconds) for 10000

5871 millis(5 seconds) for 10000

3995 millis(3 seconds) for 10000

2588 millis(2 seconds) for 10000

1529 millis(1 seconds) for 10000

[GC [ParNew: 200355K->5416K(200960K), 0.0005048 secs] 243794K->48856K(502016K), 0.0005367 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

1110 millis(1 seconds) for 10000

867 millis(0 seconds) for 10000

679 millis(0 seconds) for 10000

503 millis(0 seconds) for 10000

322 millis(0 seconds) for 10000

takes 190029 millis (190 seconds) to serialize 200000 message

Heap

 par new generation   total 200960K, used 184104K [0x10040000, 0x1da40000, 0x1da40000)

  eden space 178688K, 100% used [0x10040000, 0x1aec0000, 0x1aec0000)

  from space 22272K,  24% used [0x1c480000, 0x1c9ca360, 0x1da40000)

  to   space 22272K,   0% used [0x1aec0000, 0x1aec0000, 0x1c480000)

 concurrent mark-sweep generation total 301056K, used 43439K [0x1da40000, 0x30040000, 0x30040000)

 concurrent-mark-sweep perm gen total 16384K, used 4282K [0x30040000, 0x31040000, 0x34040000)

To post to this group, send email to java-serialization-benchmarking...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-serialization-benchmarking?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.

To post to this group, send email to java-serialization-benchmarking...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-serialization-benchmarking?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.