axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hawkins <>
Subject Re: Transport Abstraction question
Date Fri, 07 May 2004 12:10:27 GMT

Complete agreement there !

Performance can be fixed up but poor code hangs around forever ! If there
is ever a question about design or performance then we should go with the
better design. A Flexible well thought out design will enable good
performance not hinder it.

John Hawkins,

             <aslom@cs.indiana                                          To 
             .edu>                     Apache AXIS C Developers List       
             07/05/2004 04:59                                           cc 
                                       Damitha Kumarage                    
             Please respond to                                     Subject 
              "Apache AXIS C           Re: Transport Abstraction question  
             Developers List"                                              

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
>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
>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
>has finished using the given memory buffer.(see releaseBuffer(..)
>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
>own buffer. That buffer inside Expat grows finally to the size of the
>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
>in terms of memory.
>In above 2nd case Xerces allocates a buffer of around 48KB and passes it
>transport to be filled.
>So It seems that there is no point of supporting case 1 as long as there
>no XML parser that is capable of efficiently parsing (without copying to
>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