Code bloat and benchmarking database libraries, round 2
Now Shakespeare would have said, «Much ado about nothing.» In Malaysia we say: «All talk, no action-lah!» If you really are interested in speed simply install a PHP accelerator which compiles your PHP once, and subsequent requests will use the cached compiled script. Then this is a non-issue.
Some of you might say you are in a shared hosting environment and your ISP doesnt provide an accelerator. Well, the fact that youre using shared hosting probably means the ability to operate under a heavy load is not really a requirement. And I have heard of shared hosting companies kicking out users with badly designed databases and badly designed SQL, but never for parsing overhead. Gentlemen, you are missing the forest for the trees.
Heres a benchmark I recently did that demonstrates this:
This is a round-trip benchmark using a HTTP benchmarking tool, Msoft Web App Stress Tool (WAST). We measured with Turck MMCache Accelerator 2.3.23 installed and without. The tests were run as a variation of the above tests, e.g. <?php include_once(../benchdb/_adodb.inc.php); $db =& Connect(); QueryOnce($db,1); ?> Two runs were taken and averaged for each test. Higher values are better. All measurements in pages/second. With No Accelerator Accelerator MySQL 83.53 81.35 ADOdb 61.19 21.33 PEAR DB 52.85 25.26 This shows for best performance for any PHP software, you should use an accelerator that pre-compiles your PHP code. The reason why ADOdb benefits so much from an accelerator is that ADOdb is a bigger library than PEAR DB.
I must also add that the reason why ADOdb can be big but fast is that the code is designed like an onion, with a very small and fast core, and additional functionality layered on top as functions that call the core. If you dont need the extra functionality, use the core functions. And if you do need more power, its already there.
PS: I enjoy reading you guys who post at SitePoint. I might not agree with everything you say, but its great stuff.