Improvements to array.c code base
| From: | Benjamin Coutu | Date: | Tue, 20 Jan 2015 08:30:38 +0000 |
| Subject: | Improvements to array.c code base | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-80861@lists.php.net to get a copy of this message | ||
Hi Dmitry,
I was doing some code review of ext/standard/array.c and have recognized some potential for a few
performance improvements:
=== ARRAY_SLICE(..., preserve_keys=false) ===
array_slice() can always construct a packed array if preserve_keys is false, restricting it to
inputs with packed flag does not make much sense.
Removing the check for packed inputs on line 2376 would improve performance if used on non-packed
inputs with the default preserve_keys=false.
Furthermore, ZEND_HASH_FOREACH_VAL should be used instead of ZEND_HASH_FOREACH_NUM_KEY_VAL on line
2379.
It also think range() should use FAST_ZPP as it is a basic language feature (other languages even
have extra operators for it, e.g. [0..10])
=== RANGE(...) ===
range() always returns a numerically indexed array [0..count-1]. The resulting array therefore
should be constructed as a packed array (ZEND_HASH_FILL_PACKED+ZEND_HASH_FILL_ADD instead of
zend_hash_next_index_insert_new).
=== ARRAY_FILL(start_key=0, ...)
===
Just like with range(), array_fill() always returns a numerically indexed array [0..count-1] if
start_key is 0. In this special but very common case the resulting array can be constructed as a
packed array (ZEND_HASH_FILL_PACKED+ZEND_HASH_FILL_ADD instead of zend_hash_next_index_insert_new).
Another common case is for start_key to be 1. One could refine the proposed packed-array branch to
just set the first bucket to undefined in this case.
=== COUNT(...) ===
count() is so ubiquitous! Giving it an opcode and making it part of the VM seams reasonable.
Please let me know your thoughts.
Cheers,
Ben
--
Benjamin Coutu
Zeyon Technologies Inc.
http://www.zeyos.com