axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Transport Abstraction question
Date Fri, 07 May 2004 03:59:21 GMT
Lilantha Darshana wrote:

>Decoupling between transport and XML parsing need to be considered.
>There are two side of the coin when we think about performance, whether to
>sacrifice the design 
>quality and go for a poor design to improve performance. or achieve better
>performance with a clean
i would argue that superior design almost always leads to better 
performance especially if you follow up implementation phase with 
profiler to identify possible "hot spots" that may need optimization and 
will give the best performance boost.

as they say the root of all evil in programming is premature optimization :)

>Introduce a Ring Buffer Manager in between the transport layer and XML
>payload reader/writer - 
>to make it a producer/consumer model. Reading will block if the buffer does
>not have enough
>data for reading, this traps RingBufferManager to read data from transport
>and fill the buffer.
>Writing will synch data to the target. Transport layer will block until axis
>writes output to
>the RingBufferManager. 
>For Xerces we can provide a InputSource, by using above model.
>function calls like releaseBuffer(..) need to be encapsulated in the
>then the interfacing between transport and axis is cleaner.
unless Xerces-C supports something similar to Xerces-Java ability to 
return only after parsing some of input 
(pullParserConfiguration.parse(false)) then you will need two threads - 
one to get Xerces-C parsing (producer) and another that will pull events 
(consumer)? that is assuming you want to do parsing in pull mode.


>-----Original Message-----
>From: Susantha Kumara []
>Sent: Thursday, May 06, 2004 1:31 AM
>To: axis-c-dev
>Cc: Damitha Kumarage; Aleksander Slominski
>Subject: Transport Abstraction question
>Hi all,
>I am working on Transport layer and Parser layer abstraction and got
>following question,
>At the moment Axis assumes that the receiving part of the transport layer
>can behave in 2 ways.
>1.       Some transport layers allocate memory buffers / fills them with
>receiving data and gives to Axis.(see getBytes(..) function)
>Ex : When using Expat parser
>                  These transport layers want Axis to inform them when Axis
>has finished using the given memory buffer.(see releaseBuffer(..) function)
>2.       Some transport layers don't allocate memory buffers but will fill
>the given buffers (from Axis).
>Ex: When using Xerces parser.
>But generally its VERY difficult for a XML parser to use the buffers given
>by outside. Especially when the XML document is given in parts. 
>In above 1st case too Expat internally copies all data passed to it into its
>own buffer. That buffer inside Expat grows finally to the size of the whole
>XML document. But if we get a buffer allocated inside Expat and pass it to
>the transport layer to be filled and given back that would be more efficient
>in terms of memory.
>In above 2nd case Xerces allocates a buffer of around 48KB and passes it to
>transport to be filled.
>So It seems that there is no point of supporting case 1 as long as there is
>no XML parser that is capable of efficiently parsing (without copying to its
>other memory buffer) memory buffers allocated outside of the parser.
>Those who have experience in writing an XML parsers will understand this
>problem better.
>So what about supporting only case 2 in the upcoming transport API ?.

The best way to predict the future is to invent it - Alan Kay

View raw message