Re: [phplib] Re: [PHP-PEAR] PHPLib and Pear merge From: Maxim Derkachev (kot <email protected>)
Date: 03/09/01

Hello Sebastian,

Wednesday, March 07, 2001, 1:23:24 PM, you wrote:

SB> This shows what I feared for a long time: PEAR/DB is slower that PHPLIB's
SB> DB_Sql system.

SB> The question is: Is it slow by design, which'd be a pity since I like it,
SB> or is just the implementation slow?
SB> It'd be really great if someone could
SB> have a look at improving the speed of PEAR/DB.

I believe it is slow by design.
1. PHPLib's db abstraction uses _one_ *light* class, which is simply
should be extended to use it (extended class must specify only the db engine to use and
connection parameters to work). To use it there should be only _one_ object of an
extended class initialized (no db connection object, no result object of PEAR::DB,
etc ...). Some days ago you said that PHP OOP handling sucks. That is.
I guess such a large class hierarchy as PEAR::DB could not stand the
performance penalty of its over-organization.
2. The code of the PEAR::DB (say, if you intend to use MySQL), in _only_ DB part
(no other PEAR includes, that the db abstraction needs to work) weights more then 40 kb,
DB_Sql for MySQL weights less then 10 kb. That means PHP needs 4 more
time to interpret the package. Moreover, it needs to construct very
complicated DB structure to execute it.
3. Since there are several objects involved in work of the PEAR::DB, I
guess it needs much more memory then DB_Sql.

SB> Back when Kristian and I announced that PHPLIB should - from our point of
SB> view - be merged into PEAR, there was only positive feedback. And then,
SB> people went silent and now after about two months of no help offering from
SB> the PHPLIB mailing list people - they're against the merging. What do you
SB> people want?

Actually, I've spent this time to examine how PEAR::DB works :). I
found it useless to me in its current state and I'm against of using
it instead of DB_SQL in PHPLib merged into PEAR. If the use of the
PEAR::DB is a condition of merging PHPLib into PEAR, I'm against that
merge.

SB> Yesterday, the following thought formed in my head: Why not take the
SB> classes from PHPLIB that stand for themselves (like Forms, Tree, Menu) and
SB> "merge" them into the appropriate PEAR/ directories and put the PHPLIB
SB> Framework (Auth/User/Perm/Page/...) into PEAR/PHPLIB/ as a bundle of
SB> classes?

Why not? Then the question is what PEAR people think PEAR should be?
If it should be like CPAN (a repository), there is no problem. If the
way is building a framework (where, e.g., every package that use a
database _must_ use PEAR::DB), I see big problems. 

-- 
Best regards,
Maxim Derkachev mailto:kot <email protected>
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
http://www.Books.Ru -- All Books of Russia
 

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>