-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[WIP] Optimize pack() #18524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[WIP] Optimize pack() #18524
Conversation
maybe a interessting benchmark/test-case for
vs.
using the |
Unpack will always be slower than just strlen. However, your code revealed that repetitions were handled in a slow way where lots of temporary strings were created and then parsed. I opened a PR to fix that particular issue: #18803 |
could benchmark static inline void php_pack(const zval *val, size_t size,
php_pack_endianness enc, char *out)
{
zend_long z = zval_get_long(val);
if ((enc == PHP_LITTLE_ENDIAN) != MACHINE_LITTLE_ENDIAN) {
z = PHP_LONG_BSWAP(z);
}
memcpy(out, (char*)&z + sizeof(z) - size, size);
} might be faster |
Very strangely, my original code with zend_never_inline is slightly faster than master, but your code without zend_never_inline seems to beat that in my test with the 'J' specifier. Testing some more stuff... |
if the performance difference insignificant/marginal, as in hardly even benchmark-able, i would recommend just ignoring it. I like how this makes pack the code much simpler (assuming it actually works on BE) |
Co-authored-by: [email protected]
I think I managed to make the compiler happy and let it make good inlining decisions while keeping the code simple. For example for this: for ($i = 0; $i < 10_000_000; ++$i) {
pack("J", 0x7FFFFFFFFFFFFFFF);
} On an i7-4790:
And for this: for ($i=0;$i<4000000;$i++)
pack("nvc*", 0x1234, 0x5678, 65, 66); On the same machine:
Let's hope it's reproducible |
No description provided.