Re: PHP performance
| From: | Jochem Maas | Date: | Tue, 04 Mar 2008 18:05:39 +0000 |
| Subject: | Re: PHP performance | ||
| References: | 1 2 3 4 5 6 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-270956@lists.php.net to get a copy of this message | ||
Eric Butera schreef:
On Tue, Mar 4, 2008 at 5:51 AM, Jochem Maas <jochem@iamjochem.com> wrote:...Eric Butera schreef:
duh. ofcourse they do that. remove a layer of abstraction and win some speed. it a game of dimishing returns, take the big target first - that's usually the SQL queries, DB tuning. next step might be op-code caching, then data/output caching, and if that's not enough (or you have enough iron in play to make the numbers add up) you start to remove maintainability and/or abstraction from your code to win a few cpu cycles. php is web-glue, or for the purposes of my metaphor web-butter ... generally the sandwich is mostly filled with something other than butter.-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.phpHi Jochem, This is probably true. I was just referring to an old benchmark [1] I had seen a few years ago. Of course the biggest win will come from an opcode cache if that is a possibility. Just for the record I do use a db wrapper myself but I have weighed the pros and cons of the situation and determined that it works for me. I have many low traffic sites so it makes sense to have a wrapper that delays connections until they're used and such other little tweaks. I listen to peoples recoded talks from conferences and I've heard on many occasions that on single apps they take out the db abstraction. I wish I could cite references but it is out there if you want to dig enough.
[1] http://phplens.com/lens/adodb/