从 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 得到了一些非常相似的东西:现在有一些特定于类型的处理程序用于一些高频操作码,例如ZEND_ADD
. Opcache 能够推断某些变量的类型,在某些情况下,它甚至能够推断数组中变量的类型,并更改生成的操作码以使用 normal 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 版本中,无法知道可以将什么样的参数传递给函数,这使得 JIT 编译方法很难实现卓越的性能,就像 facebook 的HHVM那样。
@ircmaxell 在他的博客中提到了通过本机编译将所有这些提升到一个新水平的可能性,这甚至比 JIT 更好。
从性能的角度来看,类型标量提示为实现这些优化打开了大门。但它本身并不能提高性能。