I'm reposting this on this forum "for the record" as pointed out by "Khalid B" on the devel list
In a recent blog by Dries and in a follow post to the devel list, it was expressed that some optimisation within Drupal's database abstraction could be looked at along with SQL optimisation.
So, I decided to look into these possibilities. Given that the abstraction layer was most used (all SQL queries must pass through it) I decided to start there, with db_query().
We all know the param syntax for db_query(), a "tokenised" query string followed by one or more values to fill the tokens (or an array containing the same). So, I decided that would be where I concentrate my first efforts.
Looking at just how the tokens (placeholders, call them what you like), preg_match_callback() is used to call a helper "callback" function. This callback function is first pre-initialised with the array of parameters. Then, each time preg_match_callback() calls it, it passes off to a lower level function the actual escape sequence requirements.
All this is required to ensure Drupal doesn't "leak" an SQL injection attack by ensuring all parameters are escaped appropriately.
My first thoughts on how this all worked were "preg_match_callback" is a great filter mechanism but it has a performance penalty. First of all, the regex passed, define('DB_QUERY_REGEXP', '/(%d|%s|%%|%f|%b)/');, just says to me that using the PCRE library to do this is using a "sledgehammer to crack a nut". The PCRE does an awful lot of "stuff". Secondly, the callback mechanism from PCRE/PECL space to PHP userspace is a performance degrading operation. This normally isn't noticed, but given the large number of SQL queries generated to render a page, it all starts to add up.