design: stitching C over C++

[Aleksander Slominski <as...@cs.indiana.edu>]

Samisa Abeysinghe wrote:

> As John once said, perfomance will be there once there is a good design.

not to disappoint anybody but  am just going to post numbers and as far 
as i can see AXIS-C++ is *slower* than AXIS-Java. now would be the time 
to ask why (and use profiler)

>At the moment the design is nither functional nor OO.
>  
>
yes

>This is because its trying to support C on top of C++.
>  
>
i think you should decide what you want to support and *why
*
the why part is really important..

i can see need for small C part of AXIS-C to use in embedded devices but 
such devices will not run apache, will not have dynamic module loading 
and generally will be working in very limited memory. to keep things 
consistent you then build C++ wrapper around C core and keep everything 
else as proper C++ with good OO design, dynamic modules, apache server 
deployment etc etc

however is there any other reason to use C instead of C++ (ans simulate 
C++ in C ...)?

even this embedded use case is not that compelling when you realize that 
embedded devices are so different that one may not get a common subset 
working for them and lot o specialized solutions is needed and i doubt 
AXIS-C wants to try to do it *without* actual developers working in such 
environment!!!

>BTW I my point is not the use of a programming language, but the design of the why engine.
>
>  
>
there is more to it than just design of engine. (for example ease of use 
comes to my mind as more important factor than 1% faster engine that is 
1000% harder to use Web Services stack in C++ ..)

>Well before adding more features it has to be decided how the core desing would be affected by the
>suppoting of C. If we are to keep the adhoc design to support C users, nither those who use C nor
>C++ would benefit.
>  
>
exactly!

alek

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

RE: design: stitching C over C++

[Susantha Kumara <su...@opensource.lk>]

> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Tuesday, June 15, 2004 12:05 PM
> To: Apache AXIS C Developers List
> Subject: Re: design: stitching C over C++
> 
> --- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> > Samisa Abeysinghe wrote:
> >
> > > As John once said, perfomance will be there once there is a good
> design.
> >
> > not to disappoint anybody but  am just going to post numbers and as
far
> > as i can see AXIS-C++ is *slower* than AXIS-Java. now would be the
time
> > to ask why (and use profiler)
> >
> 
> I did not do any systematic tests on this, but I guess this is due to
> design problems.
> If we fix the wrapper model (where there are many instances that a
> perticular class calls a method
> which is just passed through a set of objects until it finds the real
> implementation - e.g. for
> timeout setting it goes like: Stub -> Call -> SOAPTrasport ->
AxisTrasport
> -> Transport ->
> HTTPTrasport -> Channel) there is a chance that we would see some
> improvement.

I agree that this is a design problem in AxisTransport module.

But see when a stub wrapper method calls getElementAsString etc. The
function call can go at the worst case like following,

Stub->Call->Deserializer->Parser->SoapTransport->........

But this function call hierarchy will not not be that issue IFF the
parameters passed either by reference or by pointers and there is no
much stack variables inside those intermediary functions (minimizing
stack operations).

> Simply this is one place where the performance hits. Even if we get a
C
> interface with this, we
> would not see any speed.
> There can also be some other areas other than the wrapper model, 
> that
> causes perfomance drops.
> I doubt this slowness is due to parsing as Axis C++ uses a pull model.

One of the two facts that Axis C++ relies on for its performance is XML
pull model. But we need following to get the full performance of XML
pull model.
1. We have to have a real pull parser (current parsers are wrapped
around SAX or DOM)
2. Both Server side and Client side transports should support chuncked
transfer.
3. Serializer should also be improved/modified to have push model.

Thanks,

Susantha
---

> Hence it has to be
> something in the classs hierarchy.
> Need to do some research and find out.
> 
> Samisa...
> 
> > >At the moment the design is nither functional nor OO.
> > >
> > >
> > yes
> >
> > >This is because its trying to support C on top of C++.
> > >
> > >
> > i think you should decide what you want to support and *why
> > *
> > the why part is really important..
> >
> > i can see need for small C part of AXIS-C to use in embedded devices
but
> > such devices will not run apache, will not have dynamic module
loading
> > and generally will be working in very limited memory. to keep things
> > consistent you then build C++ wrapper around C core and keep
everything
> > else as proper C++ with good OO design, dynamic modules, apache
server
> > deployment etc etc
> >
> > however is there any other reason to use C instead of C++ (ans
simulate
> > C++ in C ...)?
> >
> > even this embedded use case is not that compelling when you realize
that
> > embedded devices are so different that one may not get a common
subset
> > working for them and lot o specialized solutions is needed and i
doubt
> > AXIS-C wants to try to do it *without* actual developers working in
such
> > environment!!!
> >
> > >BTW I my point is not the use of a programming language, but the
design
> of the why engine.
> > >
> > >
> > >
> > there is more to it than just design of engine. (for example ease of
use
> > comes to my mind as more important factor than 1% faster engine that
is
> > 1000% harder to use Web Services stack in C++ ..)
> >
> > >Well before adding more features it has to be decided how the core
> desing would be affected by
> > the
> > >suppoting of C. If we are to keep the adhoc design to support C
users,
> nither those who use C
> > nor
> > >C++ would benefit.
> > >
> > >
> > exactly!
> >
> > alek
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
> 
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/

Re: design: stitching C over C++

[Samisa Abeysinghe <sa...@yahoo.com>]

--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> Samisa Abeysinghe wrote:
> 
> > As John once said, perfomance will be there once there is a good design.
> 
> not to disappoint anybody but  am just going to post numbers and as far 
> as i can see AXIS-C++ is *slower* than AXIS-Java. now would be the time 
> to ask why (and use profiler)
> 

I did not do any systematic tests on this, but I guess this is due to design problems.
If we fix the wrapper model (where there are many instances that a perticular class calls a method
which is just passed through a set of objects until it finds the real implementation - e.g. for
timeout setting it goes like: Stub -> Call -> SOAPTrasport -> AxisTrasport -> Transport ->
HTTPTrasport -> Channel) there is a chance that we would see some improvement.
Simply this is one place where the performance hits. Even if we get a C interface with this, we
would not see any speed.
There can also be some other areas other than the wrapper model, that causes perfomance drops.
I doubt this slowness is due to parsing as Axis C++ uses a pull model. Hence it has to be
something in the classs hierarchy. 
Need to do some research and find out.

Samisa...

> >At the moment the design is nither functional nor OO.
> >  
> >
> yes
> 
> >This is because its trying to support C on top of C++.
> >  
> >
> i think you should decide what you want to support and *why
> *
> the why part is really important..
> 
> i can see need for small C part of AXIS-C to use in embedded devices but 
> such devices will not run apache, will not have dynamic module loading 
> and generally will be working in very limited memory. to keep things 
> consistent you then build C++ wrapper around C core and keep everything 
> else as proper C++ with good OO design, dynamic modules, apache server 
> deployment etc etc
> 
> however is there any other reason to use C instead of C++ (ans simulate 
> C++ in C ...)?
> 
> even this embedded use case is not that compelling when you realize that 
> embedded devices are so different that one may not get a common subset 
> working for them and lot o specialized solutions is needed and i doubt 
> AXIS-C wants to try to do it *without* actual developers working in such 
> environment!!!
> 
> >BTW I my point is not the use of a programming language, but the design of the why engine.
> >
> >  
> >
> there is more to it than just design of engine. (for example ease of use 
> comes to my mind as more important factor than 1% faster engine that is 
> 1000% harder to use Web Services stack in C++ ..)
> 
> >Well before adding more features it has to be decided how the core desing would be affected by
> the
> >suppoting of C. If we are to keep the adhoc design to support C users, nither those who use C
> nor
> >C++ would benefit.
> >  
> >
> exactly!
> 
> alek
> 
> -- 
> The best way to predict the future is to invent it - Alan Kay
> 
> 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/