[DB-SIG] Re: DB-API wrapper with db_rows
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
> just over 14MB of memory. Performance (using the optional C
> 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
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
> to the point where there will be natural convergence. Until then the key
> 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
NeuroKode Labs, LLC
More information about the DB-SIG