Re: Re^5: Object-Oriented Perl Performance Penalty

Using object-oriented methods incurs a small but acceptable penalty,

What's acceptable is really for each individual engineer to decide. While I agree with your general point, this OP sounds like he wants the fastest possible solution. And that, unfortunately, means avoiding OO.

jdporter
...porque es dificil estar guapo y blanco.

Comment on Re: Re^5: Object-Oriented Perl Performance Penalty

Replies are listed 'Best First'.
Re^7: Object-Oriented Perl Performance Penalty by tadman (Prior) on Dec 17, 2002 at 21:35 UTC
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]
Re: Re: Re^5: Object-Oriented Perl Performance Penalty by runrig (Abbot) on Dec 17, 2002 at 21:39 UTC
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]