[Nagiosplug-devel] Re: Last call for Perl-plugin-objects

Awais Ahmad awais at eurobell.net
Thu May 27 07:33:05 CEST 2004


I really can't see anything in the 'performance' issues considering our
purpose and context.

IMO, performance for these plugins has more to do with how accurate and
consistent the results are, as opposed to how many extra milliseconds
the plugin took to execute. 
 

If I were writing an I/O multiplexing, non-blocking web server, then it
would be another matter entirely of course. The most heavily weighted
performance metric in that case might be execution time per request or
something similar. 

 
Awais Ahmad

 
 


On Thu, 2004-05-27 at 14:25, Stanley Hopcroft wrote:
> On Thu, May 27, 2004 at 01:47:00PM +0100, Paul L. Allen wrote:
> > Karl DeBisschop writes: 
> > 
> > > 2) you agree that the performance cost is acceptable. 
> > > 
> > > I can try to work on #1, but as noted above, free time is presently near
> > > zero. 
> > > 
> > > As far as #2, the judgment call is entirely in your court as far as I am
> > > concerned. 
> > > 
> > > As usual, people may disagree. But those are my opinions on the matter.
> > 
> > Perl's OOP does have significant performance costs.
> 
> If no one other than me is willing to A/B the performance of plugins
> built with the Howard Wilkinson and/or Yuval Kogman Perl OO bases, then
> claims of this nature are unhelpful.
> 
> One thing that suprised me when I did this is that even without embedded
> Perl Support, plugin performance is far more limited by IPC delays than
> method dispatch delay.
> 
> Using Mr Wilkinsons OO basis, the procedural check_ms_spooler run time
> IIRC, is no more than 5% better than the OO version.
> 
> This is the opportunity for those that like me were unconvinced of the
> merit of the proposal to post measurements demonstrating that the OO
> performance is a slug.
> 
> Yours sincerely.





More information about the Devel mailing list