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

[Paul L. Allen]

Stanley Hopcroft writes: 

> 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.

Tell that to Tom Christiansen.  OOP can have some very nasty performance
overheads, as Tom freely admits.  Sometimes you live with that because
it gives you programmer efficiency and you accept the tradeoff.  Sometimes
the OOP approach doesn't make the code any simpler or cleaner or easier
to write, and then the overhead is much harder to justify. 

> 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.

That surprises me too.  But I'm a heretic and I dislike the approach of
moving things out of the perl core and into modules, whether they are
loaded implicitly or explicitly.  The overall CPU time is not much
different, but the elapsed time due to disk seeks to find and load all
those modules may be.  I'm horrified by the number of dependent modules
a lot of perl code pulls in these days - I understand the principle of
code re-use but it's starting to get silly. 

> 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.

It depends how deep your inheritance goes.  So far it's not deep enough
to add more than 5%, according to your measurements.  Can you guarantee
that it won't get deeper in future releases?  And in something called
as frequently as a plug-in, is 5% an acceptable overhead in the first
place?  We regularly see posts here from people who have hardware that
is struggling to cope with the number of services being monitored and
ask for ways to improve performance.  On such systems, it may not just
be the 5% CPU overhead you've measured but an additional CPU overhead
caused by the extra memory usage of OOP resulting in swapping. 

In my view, there has to be a better reason than "I wrote it using OOP
because I prefer OOP" to justify using it, unless it's perl that
is used infreequently.  Unless there are compelling programming reasons
for going OOP, like making the code a lot shorter and cleaner, I'd avoid
it even if it's only a 5% overhead and you're sure the inheritance will
never go deeper.  If this were something that was run once a day I
wouldn't care much what was under the hood. 

It would be nice if all plugins were in C for greater efficiency, but
realistically that would decrease the number of new plugins that came
along because good C programmers are relatively rare.  I'd prefer a perl
plugin to no plugin at all, so live with the relative slowness of perl
plugins.  Adding another 5% overhead on top of that without any
compelling reason to do so is not sensible. 

So here's an explicit question for you (it was implied in my previous
post): is there any compelling reason why it would be a bad idea to add
this sort of functionality without an OOP framework?  Would the code be
a lot larger?  A lot less easy to comprehend?  A lot less easy to
maintain?  Would the API be harder for programmers who are comfortable
with OOP and non-OOP perl scripting to understand?  What is that 5%
buying us other than avoiding somebody having to re-implement the
functionality without OOP?  Your only justification for OOP so far
appears to be "it's only 5%."  It's not my decision to make, but if it
were I'd want a better justification than that. 

-- 
Paul Allen
Softflare Support