Hello,

We already had that discussion in private, but here is a on-list summary:

On Mon, Jan 19, 2009 at 5:39 PM, Guilherme Blanco
guilhermeblanco@gmail.com wrote:

Ok,

We'll use this method inside Doctrine ORM version 2.0, scheduled to be
released on September 1st, 2009.

One main location where we are already using it is during Hydration process.
The process of grab a DB tuple and convert it into an Object graph.
Here is the usage.

Each Object of the graph is a Value Object
(http://en.wikipedia.org/wiki/Value_object). So it does not have any
other mapping else than to-be persisted ones. No internal method
implementation is needed. All Active Record like actions are
controlled by EntityManager.

Based on that, we have a ClassMetadata that is catch based on class
name (currently based on spl_object_id, but it's too resources
expensive and I'll change that). When we get the DB tuple, we need to
find the exact ClassMetadata of that item and apply the specific
DB/PHP type castings for example. Also there's a property attribution.
Property attribution is thanks to new Reflection API. We store the
ReflectionProperty of each field and assign it when we have its
definition.

Another location where we rely spl_object_id is inside UnitOfWork
(http://martinfowler.com/eaaCatalog/unitOfWork.html). We generate a
mapping of each Entity/Collection to be persisted/updated/deleted. We
define the order of appliance of these things based on first the
generated OID (spl_object_id return) and later by Topological Sorting
(http://en.wikipedia.org/wiki/Topological_sorting). Finally, we start
the transaction and the statements.

The point is that we may have being doing a huge hydration with a lots
of relationed objects. We may be dealing with a webpage that fetches
for more than 5000 records with even more associations. All of that
runtime. So I have to say performance is something VERY important for
us.

Why will we not use SplStorage?
Because it'll be used on different places and should share the same
OID. Including couple of this component is not a viable idea since
it'll go to a more memory expensive solution, which we're trying to
optimize a lot and also will force us to include another get call
(through method call), which will fall into an even slower
implementation.

Here are two files that we have being using spl_object_id (changed now
to spl_object_hash, since the idea is to update it with Marcus'
suggestions):
Object Driver for Hydration:
http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectDriver.php
UnitOfWork for Persistance:
http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/UnitOfWork.php

Short version: Because we want a fast, easy way to associate
information (temporarily) with an object. Most of the time we use the
object id/hash as a key in an array. Basically, spl_object_hash is
fine, it would just be nice if it could be improved in speed.

All those use cases are related to a [object => data] map, which can
be solved by
SplObjectStorage:

$storage = new SplObjectStorage;
$storage[$obj1] = $data; ...
var_dump($storage[$obj1]); ...

There were three concerns:

1. Speed: the main ground for spl_object_id is speed. =>
   Splobjectstorage is faster than an array with spl_object_hash (and can
   be made even faster).
2. $storage[$obj1]['index'] = 2; This is sadly a limitation of
   ArrayAccess => It can be solved either by doing get+change+set, or
   using an ArrayObject instead of an array.
3. Memory: Since the object itself will be referenced in the storage,
   you'll have to delete it from every maps in order for GC to do its
   work. => This is a security, indeed, an object stays unique as long as
   it exists:

$a = new StdClass;
$h1 = spl_object_hash($a);
unset($a);
$b = new StdClass;
$h2 = spl_object_hash($b)
var_dump($h1===$h2); // bool(true)

Conclusion: If you clean your objects without properly taking care of
the metadata stored in the array indexed by object_id, you'll get
unexpected results anyway.

So far it looks like SplObjectStorage is fine with those use cases. If
somebody has a practical (with code) use case in which
SplObjectStorage can't be sanely used and where spl_object_id is the
only solution, please shoot.

It'll take me some time to dig into PHP source to try to implement it.
I'm not a C developer and there're more than 4 years I didn't touch a
single line o C code. Also I can read PHP source, but I'm not able to
create it.
I already spoke with Felipe which will help me solving questions about
src, but I cannot guarantee I'll be able to do the job.

Regards,

Hello Etienne,

Wednesday, December 17, 2008, 7:59:01 PM, you wrote:

Hello,

Hi Guilherme,

thanks for moving the discussion to the list.

Am Mittwoch, den 17.12.2008, 15:31 -0200 schrieb Guilherme Blanco:
[...]

It seems that Marcus controls the commit access to SPL. So I'm turning
the conversation async, since I cannot find him online at IRC.
So, can anyone review the patch, comment it and commit if approved?

Just for clarification, it is not about access, but about maintenance.
So if Marcus gives his go, we can happily apply the patch and add a few
tests (something you could start preparing now).

cu, Lars

Last time I checked with Marcus, there were concerns about disclosing
a valid pointer to the user.
I'd be happy to see a use-case where this information is really needed
heavily. The only real usecase of heavy usages seems to be to
implement sets of objects. but splObjectStorage is here for that
precise use-case...

Correct in all Etienne. The patch might be a tiny bit faster but exposes
valid pointers which is extremely bad and also allows other bad things.
That was the only reason I used md5 hashin. What I needed was something
that is really unique per object (object pointer or id plus pointer to
handler table). Since spl_object_hash() does not say how it creates the
hash it should be fine change the way it does it. Since in a new session
the hashes are of no more use we can even do that in any new version.
However I must still insist on not exposing any valid information.

Last but not least. In your code you know the maximum length of the
extression, so you can allocate the string and snprintf into it. Even
faster is to do a hexdump into a preallocated string. For the size use:
char* hash = (char*)safe_emalloc(sizeof(void*), 2, 1);
Now the dump of the two pointers.
This approach should make it a bit faster for you. Something that might
work is to create a random 128 bit hash key that is xored onto the hash
created from the two pointers. This hash key can be allocated for each
session the first time the function will be used. If you do that I am more
than happy to accept that as a replacement for current spl_object_hash().

marcus

Regards

--
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal

Best regards,
Marcus

--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil

Regards,

--
Etienne Kneuss
http://www.colder.ch

Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal