Yes, I've double checked, and you're right, deserialization does take less memory than serialization. I'd suggest though that the numbers for serialization could be improved as well, though. I'm not sure what tree size you used to generate your 1M ser to 12M deser numbers... I'm guessing it was smaller than 5,3. And it doesn't seem to scale any differently than deserialization.
From my new test, replicating your separation of ser and deser:
Created tree with 5 levels and 3 children at each level Axis used 4 MBytes to serialize 230 KBytes, a ratio of 20.0 Axis used 14 MBytes to deserialize 230 KBytes, a ratio of 64.0 Created tree with 5 levels and 4 children at each level Axis used 33 MBytes to serialize 1 MBytes, a ratio of 29.0 Axis used 70 MBytes to deserialize 1 MBytes, a ratio of 63.0 Created tree with 5 levels and 5 children at each level Axis used 138 MBytes to serialize 2 MBytes, a ratio of 47.0 Axis used 269 MBytes to deserialize 2 MBytes, a ratio of 92.0 Created tree with 5 levels and 6 children at each level Axis used 277 MBytes to serialize 7 MBytes, a ratio of 36.0 Axis used 675 MBytes to deserialize 7 MBytes, a ratio of 89.0 Created tree with 5 levels and 7 children at each level Axis used 570 MBytes to serialize 28 MBytes, a ratio of 20.0 Out of Memory deserializing 28 MBytes tree.
Imagine a server trying to handle multiple simultaneous requests to serialize a 28M tree -- say, 8. That would require over 4.5G of heap, something not supportable on any 32 bit JVM. And 8 simultaneous requests is not a very high scalability target. Granted there are things to do to work around this, like trying to break your request into smaller units, etc., but that doesn't change the scaling factor for using axis.
If there's anything I can do to help, please let me know!
-- Peter Molettiere Senior Engineer Truereq, Inc. http://www.truereq.com/
