[wsf-c-dev] Performance :(

[Samisa Abeysinghe]

I have been working on performance issues for past couple of weeks.
Dropping ops from OM and allocating ops where appropriate did not yield 
considerable performance gain.
However, changing the serialization mechanism lead to considerable 
improvement as suggested.
I am continuing to look into callgrind results and identify ares of 
improvement, and also working on statically allocating ops and dropping 
ops where appropriate.

Samisa...

Sanjiva Weerawarana wrote:
> James Clark wrote:
>>
>> At an architectural level, I think the main thing to notice is that the
>> problem is on the output side not the input side; it looks like the main
>> problem is that it's building the complete OM tree for the response that
>> it sends.
>
> Even on the Java side we found the serialization is a major perf 
> bottleneck- not only the tree creation but that stax writing was quite 
> slow too.
>
>> One way around this would be to construct an element from a pointer to a
>> function that can write the node to an axiom_output.  If the only method
>> that is called on the node is to serialize it, then the implementation
>> just calls the function pointer; if some other method is called, then it
>> calls the function pointer pausing it an implementation of axiom_output
>> that will build the full tree for an element.  I seem to remember
>> Sanjiva mentioning that the Java side does something like this.
>
> Yes- take a look at OMDataSource. Basically its a way to make any bit 
> of data look like an OMElement but when it comes to serialization the 
> underlying thing can be given the chance to write itself instead of 
> creating an OMElement and then writing out the OM. We do this now for 
> all data bound classes in the Java side.
>
> Sorry for not keeping up with this thread guys :( ... its hard to keep 
> up with all the mail when traveling with the family.
>
> Sanjiva.


-- 
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services Developers' Portal)