PHP7 中的标量和严格类型是性能增强功能吗?
从 PHP7 开始,我们现在可以使用标量类型,并基于每个文件请求严格类型。使用这些功能是否有任何性能优势?如果是,如何?
在互联网上,我只发现了概念上的好处,例如:
- 更精确的错误
- 避免不必要的类型强制问题
- 更多的语义代码,避免使用他人代码时的误解
- 更好的代码 IDE 评估
从 PHP7 开始,我们现在可以使用标量类型,并基于每个文件请求严格类型。使用这些功能是否有任何性能优势?如果是,如何?
在互联网上,我只发现了概念上的好处,例如:
今天,在 PHP7 中使用标量和严格类型并不能提高性能。
PHP7 没有 JIT 编译器。
如果在未来的某个时候,PHP确实获得了JIT编译器,那么想象可以使用其他类型信息执行的优化并不难。
当涉及到没有JIT的优化时,标量类型只是部分有用。
让我们采用以下代码:
<?php
function (int $a, int $b) : int {
return $a + $b;
}
?>
这是Zend为此生成的代码:
function name: {closure}
L2-4 {closure}() /usr/src/scalar.php - 0x7fd6b30ef100 + 7 ops
L2 #0 RECV 1 $a
L2 #1 RECV 2 $b
L3 #2 ADD $a $b ~0
L3 #3 VERIFY_RETURN_TYPE ~0
L3 #4 RETURN ~0
L4 #5 VERIFY_RETURN_TYPE
L4 #6 RETURN null
ZEND_RECV
是对接收的参数执行类型验证和强制的操作码。下一个操作码是ZEND_ADD
:
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *result;
op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();
} else if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_DOUBLE)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, ((double)Z_LVAL_P(op1)) + Z_DVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}
} else if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_DOUBLE)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_DOUBLE)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, Z_DVAL_P(op1) + Z_DVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
} else if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, Z_DVAL_P(op1) + ((double)Z_LVAL_P(op2)));
ZEND_VM_NEXT_OPCODE();
}
}
SAVE_OPLINE();
if (OP1_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op1) == IS_UNDEF)) {
op1 = GET_OP1_UNDEF_CV(op1, BP_VAR_R);
}
if (OP2_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op2) == IS_UNDEF)) {
op2 = GET_OP2_UNDEF_CV(op2, BP_VAR_R);
}
add_function(EX_VAR(opline->result.var), op1, op2);
FREE_OP1();
FREE_OP2();
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
}
如果不了解任何代码的作用,你可以看到它相当复杂。
因此,目标将完全省略,并替换为不需要执行任何检查(除了保护)或分支,因为参数的类型是已知的。ZEND_RECV
ZEND_ADD
ZEND_ADD_INT_INT
为了省略这些,并且有一个你需要能够可靠地推断的类型和编译时。例如,编译时推理有时很容易,并且是文字整数或常量。ZEND_ADD_INT_INT
$a
$b
$a
$b
从字面上看,PHP 7.1得到了一些非常相似的东西:现在有一些针对特定类型的处理程序,用于一些高频操作码,如.Opcache能够推断出某些变量的类型,它甚至能够在某些情况下推断数组中变量的类型,并将生成的操作码更改为使用 normal ,以使用特定于类型的处理程序:ZEND_ADD
ZEND_ADD
ZEND_VM_TYPE_SPEC_HANDLER(ZEND_ADD, (res_info == MAY_BE_LONG && op1_info == MAY_BE_LONG && op2_info == MAY_BE_LONG), ZEND_ADD_LONG_NO_OVERFLOW, CONST|TMPVARCV, CONST|TMPVARCV, SPEC(NO_CONST_CONST,COMMUTATIVE))
{
USE_OPLINE
zval *op1, *op2, *result;
op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
result = EX_VAR(opline->result.var);
ZVAL_LONG(result, Z_LVAL_P(op1) + Z_LVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}
同样,在不了解其中任何一个作用的情况下,您可以看出这执行起来要简单得多。
这些优化非常酷,但是,当PHP具有JIT时,最有效,最有趣的优化将会出现。
使用这些功能是否有任何性能优势?如果是,如何?
还没有。
但这是更高效的操作码生成的第一步。根据RFC:标量类型提示的未来范围:
由于标量类型提示保证传递的参数在函数体中属于某种类型(至少在最初阶段),因此可以在Zend引擎中用于优化。例如,如果一个函数采用两个浮点提示参数并使用它们进行算术运算,则算术运算符无需检查其操作数的类型。
在以前版本的php中,没有办法知道什么样的参数可以传递给函数,这使得很难像Facebook的HHVM那样使用JIT编译方法来实现卓越的性能。
@ircmaxell在他的博客中提到了通过本机编译将所有这些提升到一个新的水平的可能性,这将比JIT更好。
从性能的角度来看,类型标量提示为实现这些优化打开了大门。但其本身并不能提高性能。