Re: Followup: opinions on Search services

["John (J5) Palmieri" <johnp martianrock com>]

On Wed, 2005-04-06 at 22:01, Miguel de Icaza wrote:
> Hello,
> 
> > > This is a misnomer.  C code can be every bit as inefficient and where
> > > Python and C# are inefficient one can always go down and write modules
> > > in a lower level language.  Point is don't optimize until you need to.
> > 
> > Actually mixing unmanaged with managed code is a real performance killer 
> > for mono. ANyway, the point was more to do with memory usage and in 
> > particular how garbage collected languages are currently quite poor for 
> > implementing this - see the beagle webpage about memory usage and its 
> > problems in this instance.
> 
> Do you have data to back out your assertion on "real performance
> killer"?
> 
> Transitions from unmanaged to managed code are not as fast as the
> regular 5-7-instructions required on a call operation, but they are
> under 20 instructions for any API that does not require extensive
> marshalling (for example transforming an XmlDocument back and forth). 
> 
> Not any worse than JNI for instance. 
> 
> So your portrayal of "real performance killer" is slightly off-bases.  
> 
> We -Mono people- consider that if you can avoid the transition to
> unmanaged code you should do it by all means.  But we ourselves use it
> extensively everywhere in our base class libraries, and our compiler
> (which uses pieces that transition a few million times back and forth
> during a bootstrap) can compile 30,000 lines of code per second. 
> 
> So your statement about "real performance killer" should probably be
> qualified.  As a general purpose statement, it is as precise as stating
> that "good stuff is better than bad stuff".  Well, duh.
> 
Adding on to this, if one designs their programs correctly the actual
call overhead is negligible.  The only reason one would optimize by
using a lower level language is if a block of code, usually in some sort
of long running loop, is taking too long to finish.  In that case most
of the time is spent in the call itself rendering the overhead of making
the call negligible.

Ok, this is getting a bit off the topic.  Sufficed to say telling a
developer not to use such and such language is counter productive.

--
J5