|
|
Posted by Richard Levasseur on 03/13/06 08:25
NC wrote:
> Richard Levasseur wrote:
> >
> > What abstraction layers lose in performance (which is miniscule,
> > for the most part), they gain in ease of use, portability, and
> > maintainability.
>
> I respectfully disagree.
>
> Ease of use is a matter of opinion; what is easy to me is not
> necessarily easy to you and vice versa. Our discussion is the case in
> point; you think it is possible to simplify database access by
> introducing an abstraction layer, while I think that calls to native
> API functions are simple enough... :)
Calls to native API functions are great, but i got tired of writing the
same code over and over, copy and pasting the same code over and over,
and generally adding more code that, when a change was required, forced
me to go back through it all and fix each independent instance.
> Portability (if, in the context of this discussion, we define it as the
> application's ability to use multiple database engines) and
> maintainability are conflicting goals -- maintainability decreases with
> the size of code base, while portability requires expansion of the code
> base, so portable applications are by definition more difficult to
> maintain. Code that does not rely on abstraction layers is by
> definition more maintenable, simply because developers don't have to
> maintain the abstraction layers themselves.
Just because there is a lot of code doesn't mean it isn't maintainable
(in the sense of, "I'm going to go smoke a pack of cigarettes before I
touch this, then call a therapist afterwards").
How an abstraction layer makes it more maintainable is it becomes
easier to make changes. You only have to do a couple of things
(function calls, object creations, whatever) to get the result you
need. As compared to making the same however-many api calls again. If
those api calls were always going to be that way, forever and ever,
then sure, the one with abstraction would be harder to maintain. But,
that is rarely (if ever?) the case (oh how I pray for such a day when
it's write once and never look at it again).
Now, which is more maintainable, the code where you simply tell the
abstraction you're working with something from somewhere else (putting
pgsql://: instead of mysql://), or go ing through and changing all the
mysql_ to pgsql_, add/remove the prepares/executes, change the
number_rows to numrows, etc etc.
Thats how an abstraction makes it more maintainable. Additionally, the
code the abstraction uses to interface to the underlying thing, be it a
database, file, whatever, is going to be seperate and (i hope to god)
self contained, again, making it easier to manage the seperate parts of
the abstraction.
Personally, I opt for the abstraction. It makes my life a lot easier
and I can get more done while leaving myself the option of adding more
faster.
> Loss of performance, however, is objectively measurable and LARGE (at
> least, that's what phpLens benchmarks show, and, to the best of my
> knowledge, no one has produced a benchmark test with markedly different
> results). There is no evidence that points to "miniscule" performance
> losses you spoke of; the evidence suggests that the losses are
> substantial. If you are aware of any benchmarks that support your
> claim, please share your knowledge, and I will happily reconsider my
> position.
Just to be clear, I'm not defending PEAR::DB's performance. It does
suck.
Another clarification I should make is that most abstractions don't
produce huge performance differences, I wasn't specifically refering to
only pear::db, because pear::db is sloooow compared to even my own
abstractions i've made. To be honest, after trolling through the
pear::db code, i've been weary of using anything from pear - but its
theres, it works, and it does what i need, so i use it.
Anyways, I'm not going to argue performance details, though, not for
anything PHP. I think it, for the most part, is silly because PHP is a
scripting language. Unless you're making some fundamental errors with
how you're processing the data, you're never going to get
whiz-ping-boing performance out of it, if you want that, you might want
to pick a lower level language and use PHP as the glue between it and
the web. Thats just my honest opinion though.
> Cheers,
> NC
Perhaps I'm a bit bias though. My specs change every day I come into
work, despite my meticulous planning and tearful, heart-wrenching pleas
to keep them the same until I, at the least, get the chance to say I
actually got something done.
-Richard
Navigation:
[Reply to this message]
|