Enable OptimizedFunctionsWithoutUnpacking sniff

[Majkl578]

From readme:

PHP optimizes some internal functions into special opcodes on VM level. Such optimization results in much faster execution compared to calling standard function. This only works when these functions are not invoked with argument unpacking (...).

The list of these functions varies across PHP versions, but is the same as functions that must be referenced by their global name (either by \ prefix or using use function), not a fallback name inside namespaced code.

[lcobucci]

@Majkl578 this one looks quite interesting! How would it behave with something like:

$args = [10, 'testing'];

echo sprintf('blah blah %d blah: %s', ...$args);

[Majkl578]

Any form of unpacking kills the optimization. sprintf() is not on the list so it's not affected. Your example is a candidate for vsprintf(). :)

[lcobucci]

@Majkl578 TIL, thanks 👍

[Ocramius]

👎 from me: a single array_merge(...$arrays) is still more efficient than looping and applying the function, and the optimisation is less relevant than the actual variadic call.

[Majkl578]

array_merge() is not a specially compiled function so it's not affected.
Applies only to these functions:

		'array_key_exists',
		'array_slice',
		'boolval',
		'call_user_func',
		'call_user_func_array',
		'chr',
		'count',
		'doubleval',
		'defined',
		'floatval',
		'func_get_args',
		'func_num_args',
		'get_called_class',
		'get_class',
		'gettype',
		'in_array',
		'intval',
		'is_array',
		'is_bool',
		'is_double',
		'is_float',
		'is_long',
		'is_int',
		'is_integer',
		'is_null',
		'is_object',
		'is_real',
		'is_resource',
		'is_string',
		'ord',
		'strlen',
		'strval',

[Ocramius]

That would still mean that (if it gets compiled), this rule still applies. Besides call_user_func(), I don't think any of these make any sense with variadic arguments

[morozov]

If it gets compiled, it’ll make sense to whitelist it.

[Majkl578]

That would still mean that (if it gets compiled), this rule still applies.

I don't understand? This sniff will only report usage of ... for functions from the list above, because unpacking defeats VM optimization. You are free to use variadics with any other function.

I don't think any of these make any sense with variadic arguments

Hopefully, in this case the rule will be harmless. 😊

[Ocramius]

As long as the list doesn't expand without BC breaks, this is 👍

…

On Mon, 24 Sep 2018, 01:39 Michael Moravec, ***@***.***> wrote: That would still mean that (if it gets compiled), this rule still applies. I don't understand? This sniff will only report usage of ... for functions from the list above, because unpacking defeats VM optimization. You are free to use variadics with any other function. I don't think any of these make any sense with variadic arguments Hopefully, in this case the rule will be harmless. 😊 — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#89 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakNP62_SAMDZdZYONRQUuDxECC7ftks5ueBuvgaJpZM4W1kdE> .