This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
| <?php | |
| error_reporting(E_ALL); | |
| class StringTypeHandler { | |
| public function length() { | |
| return strlen($this); | |
| } | |
| } |
| static zend_property_info* my_copy_property_info(...) | |
| { | |
| ... | |
| #if defined(ZEND_ENGINE_2_5) | |
| if (src->accs) { | |
| int i; | |
| CHECK(dst->accs = (zend_function**) apc_pool_alloc(pool, ZEND_NUM_ACCESSORS * sizeof(zend_function *))); | |
| for (i = 0; i < ZEND_NUM_ACCESSORS; ++i) { |
| /* {{{ my_copy_property_info */ | |
| static zend_property_info* my_copy_property_info(zend_property_info* dst, zend_property_info* src, apc_context_t* ctxt TSRMLS_DC) | |
| { | |
| apc_pool* pool = ctxt->pool; | |
| assert(src != NULL); | |
| if (!dst) { | |
| CHECK(dst = (zend_property_info*) apc_pool_alloc(pool, sizeof(*src))); | |
| } |
| diff --git a/Zend/tests/accessors/automatic_setter_with_typehint.phpt b/Zend/tests/accessors/automatic_setter_with_typehint.phpt | |
| index 4915c40..1ec4e1b 100644 | |
| --- a/Zend/tests/accessors/automatic_setter_with_typehint.phpt | |
| +++ b/Zend/tests/accessors/automatic_setter_with_typehint.phpt | |
| @@ -4,8 +4,8 @@ Automatic setters can have typehints | |
| <?php | |
| class Test { | |
| - public $test { | |
| - get; set(stdClass $obj); |
| diff --git a/Zend/tests/generators/finally/finally_ran_on_close.phpt b/Zend/tests/generators/finally/finally_ran_on_close.phpt | |
| new file mode 100644 | |
| index 0000000..04a0561 | |
| --- /dev/null | |
| +++ b/Zend/tests/generators/finally/finally_ran_on_close.phpt | |
| @@ -0,0 +1,30 @@ | |
| +--TEST-- | |
| +finally is run even if a generator is closed mid-execution | |
| +--FILE-- | |
| +<?php |
| \b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)/(3[0-2]|[1-2]?[0-9])\b | |
| \b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.((?1))\.((?1))\.((?1))/(3[0-2]|[1-2]?[0-9])\b |
In order to get a bit of "hard data" on what accessors will actually be used for once they are introduced I wrote a small script that scans through a codebase, finds all getter and setter methods and checks them for various characteristics. (The analyze.php file in this Gist.)
Here are the results of running it on a Symfony (Standard) skeleton.
absoluteTotal => 18516 (486.6%)
total => 3805 (100.0%)
skipped => 124 ( 3.3%)
The [RFC for a new simple to use password hashing API][rfc] has just been accepted for PHP 5.5. As the RFC itself is rather technical and most of the sample codes are something you should not use, I want to give a very quick overview of the new API:
Everybody knows that you should be hashing their passwords using bcrypt, but still a surprising number of developers uses insecure md5 or sha1 hashes (just look at the recent password leaks). One of the reasons for this is that the crypt() API is ridiculously hard to use and very prone to programming mistakes.