[ciapug] MySQL Stored Procedures

[Tony Bibbs]

Yeah, that's not going to be very useful.  Future Propel versions will 
use the PHP PDO implementation and should be a transparent upgrade for 
users (granted PDO is enabled).  Obviously the switch to PDO will bring 
significant performance improvements.  And, as you pointed out, the 
other ORM offerings have probably changed.

Fact is, when using an ORM you are typically trading off some 
performance for flexibility.  Now, aside from using some fairly standard 
coding guidelines, I personally don't worry about performance until 
performance is an issue.  That may sound a bit short sighted but my 
point is that a lot of tuning can happen after you take you stab at 
coding.  We use APC (which requires you to adjust some of you coding 
standards for maximum benefit) and if we find Propel is a dog in some 
places we either swap it out for custom SQL or we build an SP to do the 
heavy lifting.  We'll also use tools like http_load and, if needed, 
callgrind to help identify areas where performance can be improved.

However, for normal CRUD stuff, you shouldn't need to worry about 
performance.

--Tony


Eric Junker wrote:
> carl-olsen at mchsi.com wrote:
>> How does Propel compare to MySQL Stored Procedures as far as 
>> performance (speed) goes? 
> 
> This isn't exactly the information you are looking for but I thought I 
> would mention this article from PHP Architect that compares 
> DB_DataObject, Propel and EZPDO. Figure 2 shows the number of queries 
> taken for various operations.
> 
> http://www.phparch.com/issuedata/articles/article_185.pdf
> 
> You could possibly use the results given for Propel to try to compare it 
> to MySQL stored procedures.
> 
> Keep in mind that this article was written over a year ago and since 
> that time the performance on some of these PHP ORM frameworks has most 
> likely increased.
> 
> Eric
> 
> _______________________________________________
> ciapug mailing list
> ciapug at cialug.org
> http://cialug.org/mailman/listinfo/ciapug