Re: DB performance

i'm probably a month or two away from committing an experimental db abstraction layer which encompasses current PEAR::DB functionality and does a few more things that are difficult or impossible from user-space. its implemented as an upper/lower layer, with a C library providing services to an OOP php extension. in this way, other extension writers, as well as end users may take advantage. the library is structurally organized like JDBC : DriverManager -> drivers -> [connections|statements] -> resultsets In the works : + statically compiled as well as runtime loadable drivers. + configurable buffering of rows to implement bidirectional scrolling in forward only resultsets + disconnected resultsets. these can be created in user-space and manipulated as usual. + multicolumn sorting on buffered && disconnected resultsets + resultset persistence. save a resultset to a stream, and restore later to a disconnected resultset. + resultset column binding. resultset fetches automatically update variables in the current symbol table. + all current PEAR::DB fetch modes supported, in addition to "bulk" fetches using those fetch modes (getColumn, getAll, getString) + Metadata support + better resource friendliness. connections have a configurable idle timeout, which coupled with driver manager GC, means we hopefully will have less orphan persistent connections. also, in single process multi-threaded servers, connection limits will be per-driver. + custom driver-specific functions can be implemented and accessed from PHP i have a few remaining design issues related to prepared queries and driver connection handling to resolve, but every thing else compiles ok in M$ VS6 (my Mandrake install is broken at the moment). also there will be a fair amount of testing to do given the scope of the process. i'll post more news as things progress. l0t3k Edin Kadribasic <ek@proventum.net> wrote in message news:Pine.LNX.4.21.0110061450170.18352-100000@uxa.proventum.net... > On Sat, 6 Oct 2001, Christian Stocker wrote: > > > On Sat, 6 Oct 2001, Martin Jansen wrote: > > > > > On Sat, 6 Oct 2001 12:04:33 +0200, Edin Kadribasic wrote: > > > > > > >Are there any numbers on how big is the performance loss when using PEAR::DB > > > >as opposed to using db backend functions directly? > > > > > > Some time ago during the discussion about merging PHPLIB into PEAR someone > > > (Christian Stocker?) made a performance comparison between the DB class of > > > PHPLIB and PEAR::DB. I don't remember if he also measured the time the > > > backend functions directly need, but perhaps you can find some pieces of > > > information in the mailinglist archive. > > > > yes, that was me. but i wouldn't call those benchmark tests > > scientifically correct :) and i didn't test it with the "native" backend > > functions. just a pear to phplib comparison. See > > > > http://marc.theaimsgroup.com/?l=php-pear&m=98396772605723&w=2 > > for the thread > > > > Thanks for the link. Those numbers don't look too good and confirm my > suspicion of noticable performance loss (as in pages/sec) when switching > from "native" calls to Pear. > > Pear::DB is so nice to work with that I would have a hard time switching > back from it because of the performance issues. If I remember correctly > somebody mentioned porting the package to C to address those. Any news on > that front? >