Re: [PDO] Fwd: Bug #50755 [Opn]: PDO DBLIB Fails with OOM

On Tue, Mar 30, 2010 at 12:22 AM, Lester Caine <[email protected]> wrote:
> Stanley Sufficool wrote:
>>
>> With the spatial database processing I am doing on millions of rows
>> rendering them to PDF, another layer of slowness just isn't
>> acceptable. My apps also process many transactions per second.
>>
>>
>> http://tonylandis.com/perfomance/php-adodb-pdo-mysql-database-apc-benchmark/
>>
>> Unless I'm missing something, this performance just won't work for me.
>
> See note below, but the other problem here is that it IS only comparing a
> simple raw case. The ADOdb extension works best on returning arrays of
> results and will quite consistently return identical arrays across all of
> the databases it supports. A couple of tweaks to the ADOdb code of that
> benchmark would vastly improve performance while still maintaining the cross
> database capability. ( But hard coding 'limit' causes problems with other
> drivers ;) )

Returning an array of results from large recordsets as an array lands
me back at square one with the OUT OF MEMORY bug.

There is no way ADOdb will ever out perform PDO since it performs
another copy of the data above the driver level. Just as PDO will
never outperform a well coded native interface due to another memcopy,
of at the least, pointers to data.

>
> Of cause for best speed you use numbered arrays anyway ;)
> But this is where PDO is currently falling over ... even simply switching
> off 'blob streams' would be better currently.
>

blob/clob/image/text streams are the only way some drivers will return
large object data. You can have a 2TB field of raw blob data and the
only way is to deal with it as a stream. I don't advocate the use a
database for large objects, but that's not my call and the driver
needs to handle it in a rational way. Streams are faster in some cases
since again, you are copying only the data on-demand from the driver
instead of allocating a huge in-memory  buffer and streaming the data
into it. Chances are, if the driver (like dblib) supports a streaming
interface to blobs, the driver will do it more efficiently than PHP
can.

>>> Some of the other items on the todo list for PDO are simply not fixable
>>> given the current structure of PDO - such as cross database transactions.
>>> So
>>> either PDO will only ever be a 'restrict everything to this sub set of
>>> functions' or we need to fill in the holes to allow the PDO drivers even
>>> to
>>> be considered as replacing the generic drivers in the future?
>>>
>>
>> I don't need it. If you do, file an RFC for how you think it would best be
>> done.
>>
>>> In the meantime we still need to be able to build cross database
>>> projects.
>>
>> Cross database compatibility is nice. However, I am (un)fortunate
>> enough to be tied to a particular DBMS ;)
>
> Stanley - if you have no interest in cross database working, then I would
> SERIOUSLY suggest simply comparing performance between pdo and the generic
> dblib driver. And certainly use one of the accelerators which as indicated
> in the above benchmark makes a considerable difference. I use eaccelerator
> which performs well for me.
>

PDO with my out performs the generic dblib driver because of fewer mem
copies. The generic DBLIB driver also still has the OOM bug with large
recordset statements. I'm not inclined to fix that extension.

> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>