Re: Zend_Db_Table time overhead - about 25%

Viper X wrote:

My point of view is that insisting to use another and another layers of abstraction just for the abstraction itself does not lead to good things. Table Gateway and Row Gateway patterns have their use, but they have limitations also and are not the best solution for everything.

Who is insisting that you use Table/Row Gateway for everything?  Not me.  I definitely agree that OO abstractions for data access are less speedy than writing SQL queries.  I agree that they have their use, but no solution should be employed in all situations.

Not every database query needs to be optimal.  Some queries are done infrequently.  Many performance problems cannot be solved in a scalable way with code alone -- you have to rearchitect, or use caching, or do server-level scale-out.  Performance optimization is a holistic process, involving every level of software architecture (and some hardware architecture too), so don't focus too much on any one part of it.  Sometimes writing SQL by hand is the best way to improve database access.  Sometimes it may be caching the query results.

You're right that encapsulation is a good OO principle, and centralizing the database queries makes them easier to maintain than scattering SQL throughout your code.  But that doesn't necessarily mean that we need to abandon the OO interface and write *every* SQL query by hand.  What I recommend is that we use OO classes for simplicity and convenience, and when we find some code that is a bottleneck in the app because of using the OO interface, then we can refactor that code to improve its performance.  

My example of writing your own data store module, or abandoning PHP is hyperbole on my part.  I just mean to say that there's always a point of diminishing returns when you choose coding techniques for the sake of performance over development efficiency.  Switching to programming in assembler is of course a bad idea for 99.9% of web apps.  But in very rare cases, it could be exactly the right thing to do.

Where the balance point lies is determined on a case by case basis.  Sometimes you're writing a tiny little intranet app that has only six users and doesn't need to be optimized -- but developing that app needs to be very quick and easy, because it would senseless to invest months of effort for an app to serve only six people.  Other times you're working on a high-end content management system for a highly scalable news site like Yahoo!  Then you can invest a lot of engineering time to optimize more for performance.

I think you and I are probably on the same page...

By coincidence, Rasmus Lerdorf gave a keynote at Drupalcon this week in Hungary, and reportedly he said some things that support this too.  He compared a bunch of frameworks, and observes that they all have overhead that makes them unsuitable for high-performance, high-scalability applications.  He even says that any scripting language (like PHP) is unsuitable for very high-scale apps!  
Here's an article reporting his speech:
http://www.sitepoint.com/blogs/2008/08/29/rasmus-lerdorf-php-frameworks-think-again/

Regards,
Bill Karwin