JDK-4901731 : IIOP serialization is slow for large objects
  • Type: Bug
  • Component: other-libs
  • Sub-Component: corba:idl
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2003-08-06
  • Updated: 2003-12-17
  • Resolved: 2004-12-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 04Fixed
Related Reports
Relates :  
Description
Customer Problem Description:
-------------------------------
Given the structure:

     int iters = 100000;
     HashMap h = new HashMap();
     for (int i=0; i<iters; i++) {
       h.put(new String("Hello" + i), "Hi there" + i);
     }

- Serialization of this under java.io takes 1.3s
- Serialization of this using the WLS ORB (with some fixes) takes 6.7s to 
marshal and 2.3s to unmarshal. Since we use the JDK valuehandler in our ORB it doesn't seem that this can be a valuehandler problem but something more fundamental.
- However serialization with the JDK 1.4.1_03 ORB takes 238s to marshal and 
an unbelievable 1600s to unmarshal.

Attached is a testcase. Please uncomment the lines for ORB and comment
it for java_io while testing the scenario with ORB.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_04 tiger-beta FIXED IN: 1.4.2_04 INTEGRATED IN: 1.4.2_04 tiger-b31 tiger-b32 VERIFIED IN: 1.4.2_04
14-06-2004

SUGGESTED FIX please see http://javaweb/~tao/4901731/141/webrev/ ###@###.### 2003-08-07
07-08-2003

EVALUATION it seems that the following - 1. FastCacheTable in com.sun.corba.se.internal.orbutil grows linearly, it grows for 100 new entries each time 2. CDRInputStream_1_0 use CacheTable without hashing can be changed to - 1. FastCacheTable grow exponentially, double the size everytime 2. CDRInputStream_1_0 use hashing, pass true into CacheTable's constructor, looks like CDROutputStream_1_0 is already doing this after this in my testing both input and output takes about 7s ###@###.### 2003-08-07
07-08-2003