cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] SAX stream buffering
Date Wed, 19 Nov 2003 17:15:27 GMT
Torsten Curdt wrote:

>> 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.


>> 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message