On 5/14/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Saturday 13 May 2006 12:06, Khalid B wrote:
http://jeremy.zawodny.com/blog/archives/002194.html
His main points are:
1. With abstraction layers, performance cannot be gained.
Depends on your performance measurement. Abstraction layers are not about improving system performance; they're about improving developer performance.
We could make Drupal a hundred times faster if we recoded it in hand-tweaked x86 assembler. It would take us a few years to get something even get something marginally useful, but it would be faster because we'd have eliminated a dozen abstraction layers! (PHP, C, SQL, etc.) I'd rather burn a few cycles than a few days or weeks of my time. Hardware costs less than I do.
2. Changing databases is never easy for a large site.
Depends on your codebase, and if you planned ahead.
Let me play devil's advocate here ... The problem with an abstraction layer for the database that we are proposing is that : 1. It is not complete, since engine specific SQL statements can be embedded, and hence portability will be lost in this case. There is a false sense of portability that is there. 2. It is a lowest common denominator thing, and hence is dumbed down. 3. When you want to do things in the backend because you do not want to retreive the data in the middle tier (PHP) and incurr a performance penalty, you often have engine specific syntax (think of UNIX_TIME functions for example, date intervals, ...etc.) End Devil's Advocate mode. I am not against the database creation stuff that Adrian proposed. What I see is that in the future we may move to total abstraction. If we realize that we can no longer optimize for a specific engine without losing portability, OR that we allow it at the risk of losing portability, then we should be fine. The problem is where we are under the illusion that we have something (portability and performance) but we are not.