Re: [PHP-DEV] New function proposal: spl_object_id
On 24.01.2009, at 19:19, Guilherme Blanco wrote: Hi Oskar, Yes, you can use a plain array too. I was just giving you a normal approach (ArrayAccess inherited class) because you may want a special behavior under it too. Forget SplObjectStorage docs they're outdated read the source! =) Even if you are not keen on getting into phpdoc .. maybe writing some docs and sending them to the phpdoc team list so that they can integrate them might be a good idea. regards, regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Sun, Jan 25, 2009 at 4:24 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 24.01.2009, at 19:19, Guilherme Blanco wrote: Hi Oskar, Yes, you can use a plain array too. I was just giving you a normal approach (ArrayAccess inherited class) because you may want a special behavior under it too. Forget SplObjectStorage docs they're outdated read the source! =) Even if you are not keen on getting into phpdoc .. maybe writing some docs and sending them to the phpdoc team list so that they can integrate them might be a good idea. I've WIP docs for splobjectstorage and splfixedarray already. But any help on other classes yet undocumented would be greatly appreciated. @Guilherme For spl_object_hash, it will always be 32 0-9a-f chars, so no problem about non-printable chars. @Oscar, you're attaching mapping information to objects, SplObjectStorage can do that: $storage = new SplObjectStorage(); $storage[$obj] = $callback; regards, regards, Lukas Kahwe Smith m...@pooteeweet.org Regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello Guilherme The new implementation of spl_object_hash will solve it, since it's a faster implementation than the old one. Just one hint, you should not try to echo the generated hash, since it may have non-printable chars. I don't think that will be a problem... Also, your code may still be possible to use SplObjectStorage. Etienne did a lot of research regarding how it could be used, and he showed me that a n-dimensional array is possible too. In your situation, $events should be an ArrayAccess instance, while each $events[$event] should be an SplObjectStorage. May I ask why your sample uses ArrayAccess instead of a plain array()? And ArrayAccess is an Interface, now I am bit puzzled. SplObjectStorage will only allow objects (Docs?), I register static classes as event listener, so something like this won't work: EVENT::register(myevent, Autoloader, onmyevent); // Register Autoloader::onmyevent() as event listener. A reason I wrote SplObjectStorage won't solve my usage of spl_object_hash. So don't mark spl_object_hash deprecated in 5.4 ;-) Best regards Oskar Eisemuth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hi Oskar, Yes, you can use a plain array too. I was just giving you a normal approach (ArrayAccess inherited class) because you may want a special behavior under it too. Forget SplObjectStorage docs they're outdated read the source! =) Undoubtely devs will not mark spl_object_hash a E_DEPRECATED... I'll kill each one if they want to! =P Cheers, On Sat, Jan 24, 2009 at 4:05 PM, Oskar Eisemuth patch...@gmail.com wrote: Hello Guilherme The new implementation of spl_object_hash will solve it, since it's a faster implementation than the old one. Just one hint, you should not try to echo the generated hash, since it may have non-printable chars. I don't think that will be a problem... Also, your code may still be possible to use SplObjectStorage. Etienne did a lot of research regarding how it could be used, and he showed me that a n-dimensional array is possible too. In your situation, $events should be an ArrayAccess instance, while each $events[$event] should be an SplObjectStorage. May I ask why your sample uses ArrayAccess instead of a plain array()? And ArrayAccess is an Interface, now I am bit puzzled. SplObjectStorage will only allow objects (Docs?), I register static classes as event listener, so something like this won't work: EVENT::register(myevent, Autoloader, onmyevent); // Register Autoloader::onmyevent() as event listener. A reason I wrote SplObjectStorage won't solve my usage of spl_object_hash. So don't mark spl_object_hash deprecated in 5.4 ;-) Best regards Oskar Eisemuth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello
My usage for spl_object_id wouldn't be solved with SplObjectStorage,
here is my current event handler (it uses spl_object_hash)
I still have the plan to replace it with something better but it simply works,
currently it's not possible to free an object.
EVENT::register accepts a static class or object instance.
class EVENT {
private static $events = array();
public static function register($event, $obj, $method) {
if (!isset( self::$events[$event])) self::$events[$event] = array();
if (is_object($obj)) {
$hash = spl_object_hash($obj);
} else {
$hash = $obj;
}
self::$events[$event][$hash] = array($obj, $method);
}
public static function fire($event, $eventData = null) {
if (isset(self::$events[$event])) {
foreach(self::$events[$event] as $callable)
{
call_user_func_array($callable, array($eventData));
}
}
}
}
So spl_object_id would be a nice...
Best regards
Oskar Eisemuth
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Tue, Jan 20, 2009 at 2:38 PM, Etienne Kneuss webmas...@colder.ch wrote: Hello, On Tue, Jan 20, 2009 at 2:23 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: Etienne, We all already considered to not implement spl_object_id as long as spl_object_hash is optimized. Ok then, I'll provide a patch to improve spl_object_hash's performance, which will also change it's output. Documentation will also need to be updated so that people are aware that most of the time SplObjectStorage will be a better alternative. Here is the mentioned patches: http://patches.colder.ch/php-src/spl_object_hash-5_3.patch?markup http://patches.colder.ch/php-src/spl_object_hash-HEAD.patch?markup If nobody objects, I'll commit them Sunday. Regards, Regards, Regards, On Tue, Jan 20, 2009 at 11:20 AM, Etienne Kneuss webmas...@colder.ch wrote: Hello, On Tue, Jan 20, 2009 at 1:41 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Jan 20, 2009 at 13:26, Etienne Kneuss webmas...@colder.ch wrote: Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Why? As far as i understand, the issue is that spl_object_hash() is slow and people want a faster alternatives. Although the initial reason for the faster alternative was to do maintain some classmap for a random PHP project, this has nothing to do with the fact spl_object_hash() is slow, especially compared to the proposed spl_object_id() function. People that need a faster alternative usually need it to have an efficient object hash map. So far all the use cases where a faster spl_object_hash was needed is to do exactly that. Since this is already possible, the need for spl_object_id is questionable. If there is a clear need for it, I'll be happy to implement it myself. Now, your workarounds using SplObjectStorage may work for the previous mentioned usecases - but how the frick is anyone supposed know to know about the wonders of SplObjectStorage? The doxygen is very confusing and definetly does not replace real documentation - plus it doesn't mention the things you are referring too (object = data map) or any of the other 5.3 features. So, since documentation is currently bad, we should implement some additional functions to do the same? Sorry, but your SPL documentation vendetta is irrelevant to the question at hand. -Hannes -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
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 guilhermebla...@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, On Wed, Dec 17, 2008 at 7:19 PM, Marcus Boerger he...@php.net wrote: Hello Etienne, Wednesday, December 17, 2008, 7:59:01 PM, you wrote: Hello, On Wed, Dec 17, 2008 at 7:29 PM, Lars Strojny l...@strojny.net wrote: Hi Guilherme, thanks for moving the discussion to the list. Am Mittwoch, den 17.12.2008, 15:31 -0200 schrieb Guilherme
Re: [PHP-DEV] New function proposal: spl_object_id
Hi, I had a talk with Marcus, and he has agreed on this proposed solution: 1) SPL generates a pseudo-random session id/mask (for the current request, do not confuse with $_SESSION), which consists of 32 random bytes/characters. 2) The object is and the handler pointer are used to create a unique identifier for the object, by padding each pointer to 16 bytes and joining them together. 3) The resulting byte sequence is XOR-red with the session mask so the object id/handler are not retrievable in userland, and the resulting sequence/string is returned. This is better than spl_object_hash for two reasons: 1) no printf of numbers, no expensive md5 hashing, no hex conversion. 2) no possible collisions Drawbacks: 1) might generate some non-printable chars after xor (but this wouldn't matter for operation). The idea above can be tweaked to solve this. The 32-bit string format is to preserve compatibility with spl_object_hash, so it can replace it, instead of introducing a new similar function. I've had no time to look further into this, but Marcus seems to like the basic idea, so feel welcome... Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Tue, Jan 20, 2009 at 11:47 AM, Stan Vassilev | FM sv_for...@fmethod.com wrote: Hi, I had a talk with Marcus, and he has agreed on this proposed solution: 1) SPL generates a pseudo-random session id/mask (for the current request, do not confuse with $_SESSION), which consists of 32 random bytes/characters. 2) The object is and the handler pointer are used to create a unique identifier for the object, by padding each pointer to 16 bytes and joining them together. 3) The resulting byte sequence is XOR-red with the session mask so the object id/handler are not retrievable in userland, and the resulting sequence/string is returned. This is better than spl_object_hash for two reasons: 1) no printf of numbers, no expensive md5 hashing, no hex conversion. 2) no possible collisions Drawbacks: 1) might generate some non-printable chars after xor (but this wouldn't matter for operation). The idea above can be tweaked to solve this. The 32-bit string format is to preserve compatibility with spl_object_hash, so it can replace it, instead of introducing a new similar function. I've had no time to look further into this, but Marcus seems to like the basic idea, so feel welcome... Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Thanks. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
On Tue, Jan 20, 2009 at 13:26, Etienne Kneuss webmas...@colder.ch wrote: Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Why? As far as i understand, the issue is that spl_object_hash() is slow and people want a faster alternatives. Although the initial reason for the faster alternative was to do maintain some classmap for a random PHP project, this has nothing to do with the fact spl_object_hash() is slow, especially compared to the proposed spl_object_id() function. Now, your workarounds using SplObjectStorage may work for the previous mentioned usecases - but how the frick is anyone supposed know to know about the wonders of SplObjectStorage? The doxygen is very confusing and definetly does not replace real documentation - plus it doesn't mention the things you are referring too (object = data map) or any of the other 5.3 features. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Tue, Jan 20, 2009 at 1:45 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: Hi, It seems SplObjectStorage will solve my issue. We already spoke on pvt about how to handle things correctly too. Although this solve my issue, the point that Stan highlighted is valid. You may not find a good place where to use it, but spl_object_hash is there and it has drawbacks. Just naming collision possibility is enough to convince me about function change, even though I can't imagine a usage of it now. If none can find a usage, so we can drop spl_object_hash, right? This is not possible for BC reasons. Also, changing it internally so it no longer returns a md5 hash might be doable but it will have some BC effects as well. If those effects are considered to be harmless, then sure, I'd be happy to make that function faster by implementing what was discussed before. If you don't agree, then we need some change to make it faster and non-collision proof. Regards, Regards, On Tue, Jan 20, 2009 at 10:26 AM, Etienne Kneuss webmas...@colder.ch wrote: Hello, On Tue, Jan 20, 2009 at 11:47 AM, Stan Vassilev | FM sv_for...@fmethod.com wrote: Hi, I had a talk with Marcus, and he has agreed on this proposed solution: 1) SPL generates a pseudo-random session id/mask (for the current request, do not confuse with $_SESSION), which consists of 32 random bytes/characters. 2) The object is and the handler pointer are used to create a unique identifier for the object, by padding each pointer to 16 bytes and joining them together. 3) The resulting byte sequence is XOR-red with the session mask so the object id/handler are not retrievable in userland, and the resulting sequence/string is returned. This is better than spl_object_hash for two reasons: 1) no printf of numbers, no expensive md5 hashing, no hex conversion. 2) no possible collisions Drawbacks: 1) might generate some non-printable chars after xor (but this wouldn't matter for operation). The idea above can be tweaked to solve this. The 32-bit string format is to preserve compatibility with spl_object_hash, so it can replace it, instead of introducing a new similar function. I've had no time to look further into this, but Marcus seems to like the basic idea, so feel welcome... Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Thanks. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Etienne, We all already considered to not implement spl_object_id as long as spl_object_hash is optimized. Regards, On Tue, Jan 20, 2009 at 11:20 AM, Etienne Kneuss webmas...@colder.ch wrote: Hello, On Tue, Jan 20, 2009 at 1:41 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Jan 20, 2009 at 13:26, Etienne Kneuss webmas...@colder.ch wrote: Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Why? As far as i understand, the issue is that spl_object_hash() is slow and people want a faster alternatives. Although the initial reason for the faster alternative was to do maintain some classmap for a random PHP project, this has nothing to do with the fact spl_object_hash() is slow, especially compared to the proposed spl_object_id() function. People that need a faster alternative usually need it to have an efficient object hash map. So far all the use cases where a faster spl_object_hash was needed is to do exactly that. Since this is already possible, the need for spl_object_id is questionable. If there is a clear need for it, I'll be happy to implement it myself. Now, your workarounds using SplObjectStorage may work for the previous mentioned usecases - but how the frick is anyone supposed know to know about the wonders of SplObjectStorage? The doxygen is very confusing and definetly does not replace real documentation - plus it doesn't mention the things you are referring too (object = data map) or any of the other 5.3 features. So, since documentation is currently bad, we should implement some additional functions to do the same? Sorry, but your SPL documentation vendetta is irrelevant to the question at hand. -Hannes -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Tue, Jan 20, 2009 at 2:23 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: Etienne, We all already considered to not implement spl_object_id as long as spl_object_hash is optimized. Ok then, I'll provide a patch to improve spl_object_hash's performance, which will also change it's output. Documentation will also need to be updated so that people are aware that most of the time SplObjectStorage will be a better alternative. Regards, Regards, On Tue, Jan 20, 2009 at 11:20 AM, Etienne Kneuss webmas...@colder.ch wrote: Hello, On Tue, Jan 20, 2009 at 1:41 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Jan 20, 2009 at 13:26, Etienne Kneuss webmas...@colder.ch wrote: Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Why? As far as i understand, the issue is that spl_object_hash() is slow and people want a faster alternatives. Although the initial reason for the faster alternative was to do maintain some classmap for a random PHP project, this has nothing to do with the fact spl_object_hash() is slow, especially compared to the proposed spl_object_id() function. People that need a faster alternative usually need it to have an efficient object hash map. So far all the use cases where a faster spl_object_hash was needed is to do exactly that. Since this is already possible, the need for spl_object_id is questionable. If there is a clear need for it, I'll be happy to implement it myself. Now, your workarounds using SplObjectStorage may work for the previous mentioned usecases - but how the frick is anyone supposed know to know about the wonders of SplObjectStorage? The doxygen is very confusing and definetly does not replace real documentation - plus it doesn't mention the things you are referring too (object = data map) or any of the other 5.3 features. So, since documentation is currently bad, we should implement some additional functions to do the same? Sorry, but your SPL documentation vendetta is irrelevant to the question at hand. -Hannes -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New function proposal: spl_object_id
Shouldn't you be using RETURN_STRINGL with length and dup=0?
Andi
-Original Message-
From: Guilherme Blanco [mailto:guilhermebla...@gmail.com]
Sent: Wednesday, December 17, 2008 9:31 AM
To: internals Mailing List
Subject: [PHP-DEV] New function proposal: spl_object_id
Hi,
I spoke with some devs yesterday about spl_object_hash performance and
alternatives to solve it.
Seems that md5 applied inside it is the responsable for that.
After some tips from Lars, we came with a patch (at the bottom of this email).
The new proposed function is already being used in Doctrine 2.0 (to be
released in 2009), which takes advantages of new features of 5.3.
During our tests, everything passed without conflicting or leading to
unpredictable values.
The performance did not increase too much as I expected, but it
reached to a good value for me now. It's as fast as calculating the
spl_object_hash once and do a method call, which is an interesting
value.
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?
Thanks in advance,
Index: ext/spl/php_spl.c
===
RCS file: /repository/php-src/ext/spl/php_spl.c,v
retrieving revision 1.52.2.28.2.17.2.33
diff -u -r1.52.2.28.2.17.2.33 php_spl.c
--- ext/spl/php_spl.c 30 Nov 2008 00:23:06 - 1.52.2.28.2.17.2.33
+++ ext/spl/php_spl.c 16 Dec 2008 19:05:05 -
@@ -682,6 +682,23 @@
}
/* }}} */
+/* {{{ proto string spl_object_id(object obc)
+ Return id for the given object */
+PHP_FUNCTION(spl_object_id)
+{
+ zval *obj;
+ char *string;
+ int len;
+
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, o, obj) ==
FAILURE) {
+ return;
+ }
+
+ len = spprintf(string, 0, %p%d, Z_OBJ_HT_P(obj),
Z_OBJ_HANDLE_P(obj));
+ RETURN_STRING(string, 1);
+}
+/* }}} */
+
PHPAPI void php_spl_object_hash(zval *obj, char *md5str TSRMLS_DC) /* {{{*/
{
int len;
@@ -798,6 +815,10 @@
ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_hash, 0, 0, 1)
ZEND_ARG_INFO(0, obj)
ZEND_END_ARG_INFO()
+
+ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_id, 0, 0, 1)
+ ZEND_ARG_INFO(0, obj)
+ZEND_END_ARG_INFO()
/* }}} */
/* {{{ spl_functions
@@ -813,6 +834,7 @@
PHP_FE(class_parents, arginfo_class_parents)
PHP_FE(class_implements,arginfo_class_implements)
PHP_FE(spl_object_hash, arginfo_spl_object_hash)
+ PHP_FE(spl_object_id, arginfo_spl_object_id)
#ifdef SPL_ITERATORS_H
PHP_FE(iterator_to_array, arginfo_iterator_to_array)
PHP_FE(iterator_count, arginfo_iterator)
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
Re: [PHP-DEV] New function proposal: spl_object_id
Hello, On Wed, Dec 17, 2008 at 7:29 PM, Lars Strojny l...@strojny.net wrote: 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... 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
Hi Andi, Am Mittwoch, den 17.12.2008, 10:33 -0800 schrieb Andi Gutmans: Shouldn't you be using RETURN_STRINGL with length and dup=0? Yes, the more recent implementation does exactly that :) cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] New function proposal: spl_object_id
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 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] New function proposal: spl_object_id
Hello Etienne, Wednesday, December 17, 2008, 7:59:01 PM, you wrote: Hello, On Wed, Dec 17, 2008 at 7:29 PM, Lars Strojny l...@strojny.net wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
