Thread: [Phplib-users] phplib vs. pear
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Daniel B. <bo...@io...> - 2002-05-06 23:57:25
|
What is the status of bringing together pear and phplib? There was quite a bit of discussion about it about a year ago, but nothing since. There is even a sf project dedicated to it, but there is nothing new or interesting there. http://sourceforge.net/projects/pear-phplib/ |
|
From: Richard A. <rh...@ju...> - 2002-05-07 01:11:40
|
At 4:57 PM -0700 6/5/02, Daniel Bondurant wrote: >What is the status of bringing together pear and phplib? There was >quite a bit of discussion about it about a year ago, but nothing since. While I can't speak for the other members of the development team, I certainly don't intend to spend any time moving PHPLIB into PEAR. If PEAR ever evolves into a distribution network like CPAN and loses the elitest attitude I might re-think my position. The last thing I want is some overlord telling me how to write my code. In the meantime, I've not heard of any problems running PEAR classes alongside PHPLIB. ...R. |
|
From: Saulius <sa...@ye...> - 2002-05-07 06:58:20
|
Hello, > If PEAR ever evolves into a distribution network like CPAN and > loses the elitest attitude I might re-think my position. The last > thing I want is some overlord telling me how to write my code. Yesterday I did some tests on various db abstration layers (libriaries): native mysql, phplib, adodb, pear, metabase. What I can say about pear db, it is a big looser - latency is very big, queries work enough slow. By speed there are two groups: 1) mysql, phplib, adodb; 2) pear, metabase. I think it's not effective to use pear db in projects. Bye, Saulius |
|
From: Kristian K. <kr...@ko...> - 2002-05-09 15:43:30
|
On Tue, May 07, 2002 at 08:57:58AM +0200, Saulius wrote: > By speed there are two groups: 1) mysql, phplib, adodb; 2) pear, > metabase. I think it's not effective to use pear db in projects. From an OO design POV phplib has extremely badly designed database classes. That's why they are that fast. :-) No, really, PHPLIB was written on and for PHP3. That is an environment where classes really are nothing more than namespaces, and where state and code cannot be kept efficiently in memory, like for example it would be possible in an application server and with truly compiled code. OO design techniques strongly favor such an appserver execution environment, and PHP does not offer such an environment at all, in fact, it almost offers the antithesis to such an environment. PHPLIB was written with the particular execution model used in PHP in mind and tested on sun4m hardware. That's why it performs adequately, even today. It is not a bit fashionable, though. Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG |
|
From: Tarique S. <ta...@sa...> - 2002-05-10 01:44:58
|
On Thu, 9 May 2002, Kristian Koehntopp wrote: > No, really, PHPLIB was written on and for PHP3. That is an environment > where classes really are nothing more than namespaces, and where Hey, nice to know you still follow this list Thanks Tarique -- ============================================================= PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug ============================================================= |
|
From: Chris J. <ch...@ch...> - 2002-05-22 21:45:41
|
Along these same lines, at what point in execution does OO usage in PHP most suffer? That is, it sounds like to me that the appserver helps efficiency by maintaining environment and variable state. If I use PHP and PHPLIB in a long-running (e.g. more than 1 hour) batch script instead of as a webserver script, do the OO costs become a much smaller part of the calculation? Are the OO costs mostly start-up and instantiation of the objects? Thus, if my script initializes things once, creating the objects it needs and then (mostly) does not create/destroy objects each iteration, am I likely to see pretty good efficiency? PHP and PHPLIB's DB classes make a very powerful and easy to use tool for writing batch scripts which have to interact with a database, as well as with flat files. I'm already doing a lot of this. I'm just curious if I'm really inefficient at execution time. ..chris ----- Original Message ----- From: "Kristian Koehntopp" <kr...@ko...> On Tue, May 07, 2002 at 08:57:58AM +0200, Saulius wrote: > By speed there are two groups: 1) mysql, phplib, adodb; 2) pear, > metabase. I think it's not effective to use pear db in projects. >From an OO design POV phplib has extremely badly designed database classes. That's why they are that fast. :-) No, really, PHPLIB was written on and for PHP3. That is an environment where classes really are nothing more than namespaces, and where state and code cannot be kept efficiently in memory, like for example it would be possible in an application server and with truly compiled code. OO design techniques strongly favor such an appserver execution environment, and PHP does not offer such an environment at all, in fact, it almost offers the antithesis to such an environment. PHPLIB was written with the particular execution model used in PHP in mind and tested on sun4m hardware. That's why it performs adequately, even today. It is not a bit fashionable, though. Kristian -- |
|
From: Tarique S. <ta...@sa...> - 2002-05-07 08:20:05
|
On Tue, 7 May 2002, Richard Archer wrote: > If PEAR ever evolves into a distribution network like CPAN and > loses the elitest attitude I might re-think my position. The last > thing I want is some overlord telling me how to write my code. Also the insistance that only one Class for one task is pretty stupid and against the spirit of freedom. Tarique -- ============================================================= PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug ============================================================= |
|
From: Peter B. <re...@f2...> - 2002-05-07 11:40:10
|
At 08:57 AM 5/7/02 +0200, Saulius wrote: >Yesterday I did some tests on various db abstration layers (libriaries): >native mysql, phplib, adodb, pear, metabase. What I can say about pear db, >it is a big looser - latency is very big, queries work enough slow. By >speed there are two groups: 1) mysql, phplib, adodb; 2) pear, metabase. I >think it's not effective to use pear db in projects. Did your tests include the time to include the library files? For instance, when John Lim tested them he only started timing *after* the classes had been included but before they were initialised. If you alter it to start timing before the classes are included then the output is not quite so unfavourable for PEAR. See http://www.dybnet.de/MDB/benchmarks.pdf for some more test results. But I agree, PEAR is slow... it's just got a decent architecture and good separation of the classes, and is let down by PHP itself... Peter. -- Maple Design - quality web design and programming http://www.mapledesign.co.uk |
|
From: Saulius <sa...@ye...> - 2002-05-07 11:58:50
|
Hello, > classes had been included but before they were initialised. If you > alter it to start timing before the classes are included then the output > is not quite so unfavourable for PEAR. Yes. Exactly I altered tests and stated timing before any includes. And I was suprised. For example, doing 1 query (after altering tests) took: mysql: 0.03 sec, phplib: 0.06 sec, adodb: 0.14 sec, pear: 0.17 sec. Diference among phplib and pear is enough big: 0.11 sec. So I think, pear is too slow and very unefective. If it would be interesting I could put results in website. > See http://www.dybnet.de/MDB/benchmarks.pdf for some more test results. My test were taken from that site (http://phplens...). Bye, Saulius |
|
From: S. <bj...@ba...> - 2002-05-07 08:50:55
|
* Daniel Bondurant wrote:
> What is the status of bringing together pear and phplib?
PHPLIB::Template has been converted to PEAR (HTML_Template
in it, not yet released as a package).
--
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
Webapplikationsentwicklung * PHP-Schulungen * Consulting
0700-THINKPHP -*- bj...@th...
|
Thanks for helping keep SourceForge clean.
X