cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [RT] SAX stream buffering
Date Wed, 19 Nov 2003 17:49:55 GMT
> 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.

Well, on each array "resize" we need to create a new one and copy.
You wouldn't want to do this too often of course. Doubling the
buffer size is a common approach.

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

Not yet. But every SAX event is an object. Even if we recycle the
SaxBuffer object it will hand over all the event objects to the GC.

With the XMLC there is much less work for the GC

View raw message