As far as I can tell, Perl caches any inherited function lookups once they are performed, so after the first call, subsequent calls are just as fast as if they were in the class package. In the majority of cases, you can hardly tell the difference.
Using object-oriented methods incurs a small but acceptable penalty, and considering practical benefits, it's often worth the expense. An object-oriented approach is not always the most effective, admittedly, but it's often close enough that the differences are often a matter of preference.
| [reply] |
| [reply] |
The solution proposed by Fletch is what I would do, outside of moving to the object-oriented approach.
If you're talking absolute speed, then maybe you'd want to stay away from an object-oriented solution, but I think in practical terms, especially considering the huge DB overhead, the measurable difference in terms of performance is going to be 1% or less, which is to say, external variables will have more of an effect (i.e. CPU load, network traffic, etc.).
What I mean to suggest is that just because an object oriented technique is "slower" doesn't mean that it must be avoided. "Fastest possible" is certainly not meant to be taken at its most extreme interpretation, because if that were the case, you can forget about using Perl at all.
| [reply] |
this OP sounds like he wants the fastest possible solution
This OP also said he was a novice, and may not know what exactly is close enough to being the "fastest possible" (and besides, he lists first on his list of priorities "maintainable"). The bottleneck here will be loading the database, and a few extra seconds (if even that) processing the data will probably be insignificant compared to that. That being said, I think Fletch's answer is probably the most straightforward for the problem as stated (and that being said, I'm not even sure I fully understand the problem myself :-)
| [reply] |