[DB-SIG] Re: DB-API wrapper with db_rows

Jon Franz jfranz at neurokode.com
Sat Jan 3 16:16:40 EST 2004


[ Kevin Jacobs wrote ]
>   3) db_rows must be light-weight and fast.  E.g., a result set of 200,000
>      result tuples may take 13MB of memory, the same result as a list of
>      dictionaries takes about 117MB of memory, while a list of db_rows
takes
>      just over 14MB of memory.  Performance (using the optional C
extension)
>      is very competitive with tuples and much better than dicts.

One thing of note: PDO only provides an dictionary interface, it does not
create dictionaries in memory -
the actual memory usage of a PDO resultset is very close to the original
sequence of tuples - and the overhead is fairly constant on a per-column
level (not per-row) basis.  Performance is very good, but of course not as
fast as tuples.  Even per-column metadata, such as type_id and size, are all
stored once, not per row.  PDO uses interface tricks, not actual
dictionaries (except for the internal column-name-to-index lookup, of
course).  In your example, I'm pretty sure PDO would be between 13MB and
14MB in size.

In other words, PDO is also lightweight and fast, thus point #3 actually
reveals a commonality between PDO and db_rows, not a difference.

> Thanks, but I'm not much of a fan of ADO-style interfaces.

Just curiosity, but what about ADO/JDBC/delphi-data-object style interfaces
puts you off?  I always find myself abhorring things like DBD/DBI and many
of the chosen methods of doing things with the DB-API, and longing for a
higher-level interface - so hearing from the opposite viewpoint may do me
some good.

Bryan Gudorf and myself realized awhile ago that our wants/needs are
sometimes just semantic, and even the additional features we wanted could be
handled by a wrapper of the DB-API - hence PDO's existence.

> However, I have
> looked at a few versions of PDO and think it is great for those that are.
> We have a long way to go before the current generation of interfaces
mature
> to the point where there will be natural convergence.  Until then the key
is
> for the various implementers to keep an open mind, track what is happening
> with other projects, and share ideas so that we're not stuck continually
> re-inventing the same wheels.

I guess you looked at the documentation and not the code?  Perhaps we should
modify the documentation to explicitly note that only a dictionary interface
is provided and that the actual implementation is lightweight and fast.
I completely agree on the need to keep an open mind and track other
projects.

~Jon Franz
NeuroKode Labs, LLC




More information about the DB-SIG mailing list