Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Alan Pinstein <apinstein@mac.com>
Full name Alan Pinstein <apinstein@mac.com>
Date 2006-10-03 06:07:14 PDT
Message If you're concerned about hydrate performance, you might want to
check out the patch I recently committed to creole. It does 2 things:

1. move the require_once statements to the top of the file so that
they are called exactly once, rather than N times.
2. replace array_key_exists() with isset() to test for column
existence; it's much faster. Done only for ResultSetCommon and PGSQL.
Would need to be "cloned" to other drivers too, but shouldn't cause
any breakage as-is. Also changes an is_int() call for a simple var
test, which is marginally faster.

These two things made a pretty big difference for me.

The more columns your table has, the more impact #2 has, b/c
array_key_exists() was being called for EACH COLUMN, and it's really

NOTE: I patched only the PGSQL version for #2 since it's the only one
I use. But it's very little code; you could patch another driver in 5
minutes by following the diff from the root of the trunk folder:

svn diff -r 53 .


On Oct 3, 2006, at 8:13 AM, David Z├╝lke wrote:

> Sven,
> I looked at your suggestion in detail and I believe it makes a lot
> of sense.
> I think on-the-fly fetching of result sets should result in roughly
> the same performance as the traditional array population method,
> but it will have to very significant advantages:
> 1) memory consumption is a lot lower, e.g. when iterating over 1000
> rows to display them, a row is fetched, the data is displayed, and
> the GC can then go ahead and destroy the object.
> 2) it opens the door for a potential
> CategoryPeer::doSele​ctJoinProducts() support, where fetching 1:n
> relations with a join would become possible.
> David
> Am 02.10.2006 um 10:43 schrieb Sven Tietje:
>> Hi,
>> i`d like to create a PropelResultset to make it possible to
>> iterate over
>> Resultsets and to hydrate objects on the fly. We have talked about
>> it.
>> One of propel`s performance problems are the Result-Arrays.
>> $resultArrray = TablePeer::doSelect(new Criteria());
>> doSelect queries the database. A Resultset is given. Now, Propel
>> fetches
>> each row of the resultset, hydrates the row into an object and
>> puts the
>> object into an array. Having fetched all rows, doSelect returns the
>> array.
>> I think BasePeer should return a PropelResultset.
>> class PropelResultset implements IteratorAggregate, ArrayAccess,
>> Countable {
>> public function setFetchMode();
>> .... Interface - Methods
>> }
>> - ArrayAccess and Countable will make PropelResultset
>> backwards-compatible to the normal array.
>> - setFetchMode will give you two possiblities:
>> 1) PropelResultset::OBJECT - enabled by default
>> $resultset->setF​etchMode(PropelResul​tset::OBJECT);
>> foreach ($resultset as $item) {
>> $item->getPrimaryKey();
>> $item->set...;
>> $item->save();
>> }
>> 2) PropelResultset::ARRAY - sometimes you don`t need objects
>> $resultset->setF​etchMode(PropelResul​tset::ARRAY);
>> foreach ($resultset as $item) {
>> $item[TablePeer::ID];
>> $item[TablePeer::TITLE];
>> }
>> Key of the $item - Array is of structure:
>> tablename.columname or tablealias.columnname
>> Perhaps we also should discuss a BaseObject implementing ArrayAccess
>> directly.
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org