I'm not very surprised by these numbers: XMLC does a pretty heavy job to serialize Strings to bytes.
Furthermore, I just looked at the XMLByteStreamCompiler.write() which shows that it spends most of its time resizing the byte buffer, as resizing is limited to the actual number of bytes needed for the current write, and not by a larger growth increment.
It would be interesting to redo the test by introducing this growth increment. BTW, I don't understand the "this.buf.length << 1" in the write() method.
Well, thats not exactly true:
buf.length << 1 is a shift operation which is the same as buf.length*2. The Max() chooses the bigger value.
So that method is fine ;)
Yep. It's been such a long time that I've not used shift operators that I was suspecting some black magic here ;-)
No the problem may be the opposite, and the XMLC may be eating way too much memory: a linear growth rate would be IMO better.
<snip/>
Can't we merge both: use SAXBuffer for in-memory storage, and use XMLC/XMLI to serialize it? This could even be done transparently by having SAXBuffer implementing Serializable and use XMLC/XMLI to implement readObject() and writeObject().
Hm... I don't know if I like that. Although it also came to my mind.
That way we *always* have the memory consumption. It sounds reasonable from a OOP POV but it might not be a good choice in terms of scaleability ...I assume :-/
Any numbers on SAXBuffer's memory consumption?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
