Часто ли вам приходится заниматься приведением типов в РНР?

[grigori]

Проверять надо хотя бы как тут: https://github.com/Roave/FunctionFQNReplacer

согласен, что на уровне ассемблера разница академически очень вероятна - написать eval(), например,
но как заметить ее в какой-нибудь практической ситуации - не представляю, если имена функций резолвятся при компиляции

 

[fixxxer]

если имена функций резолвятся при компиляции

Нет же, ну посмотри на опкоды по ссылочке.

PHP компилирует per file, а не per project, он не может знать, есть ли функция в неймспейсе. (Это, кстати, будет главной проблемой для JIT).

 

[grigori]

ну да - мы же можем объявить функцию на лету по условию,
а возможно ли отловить разницу скорости исполнения в коде без eval или тысяч вызовов его аналога call_user_func()?

 

[fixxxer]

Сейчас это копейки, но с JIT разница явно будет на порядок минимум

 

[grigori]

надо будет посмотреть на jit - может быть, он будет быстро работать по preload-коду, а любые динамические вызовы вне зависимости от namespace будут отрабатываться в интерпретаторе, и получится, что динамические вызовы тормозят как у фишера независимо от NS

 

[AmdY]

нихрена нет разницы, вообще \in_array писать или in_array

<?php
namespace C;
class A
{
    public static function foo(){
        for($i=0;$i<2000000;++$i) \in_array(1,[1,2]);
    }
}

$start = microtime(true);
A::foo();
echo microtime(true) - $start;

я же говорю о костылях https://github.com/php/php-src/blob/f2db305fa4e9bd7d04d567822687ec714aedcdb5/Zend/zend_compile.c#L3930

 

[fixxxer]

надо будет посмотреть на jit - может быть, он будет быстро работать по preload-коду, а любые динамические вызовы вне зависимости от namespace будут отрабатываться в интерпретаторе, и получится, что динамические вызовы тормозят как у фишера независимо от NS

От JIT, который сваливается в VM при любом вызове, толку никакого - будет хуже, чем без него (да, ровно как в Blitz с колбэками).
Сваливаться в VM при вменяемо реализованном JIT надо будет только для всякой жести типа eval().

Динамика PHP в смысле вызовов очень похожа на динамику Objective-C - делается hashmap с табличкой переходов.
Для функций, написанных на C, никакая табличка не нужна - достаточно обычного статического вызова из "стандартной библиотеки". Часть случаев (заведомо объявленная функция (в том же файле), private или final метод через $this->/self) тоже оптимизируется в статику. Кстати, вот тут правило "abstract or final" даст нехилый прирост производительности.

Так что \in_array скомпилируется в статику, а с in_array получится на каждый вызов лишний лукап в этой самой hashtable.

Кстати, Blitz с JIT, по идее, будет работать быстрее - лукап по hashtable из рантайма PHP-JIT - это явно быстрее переключения в VM. (Хотя пофиг на Blitz, конечно).

 

[fixxxer]

работать по preload-коду

Это поможет, если весь preload будет компилироваться в одну "библиотеку". Тогда можно многое отрезолвить статически - и, кстати, еще важнее станет использование final (все вызовы методов final класса, если он в preload, можно скомпилить в статику).

Возможно, идея прелоада как раз в этом (не просто так же он появился во время резерча JIT)!

 

[grigori]

"Preloading позволяет связать классы изначально и, соответственно, генерировать код более оптимально. Использование preloading помогает при глобальной оптимизации всех PHP-скриптов, полностью убирает накладные расходы OPcache и позволяет генерировать более эффективный JIT-код.", - Стогов

 

[Full-R]

Иногда пишу (bool) (int) (string) в if из-за людей, которые отвлекают. А так обычно strict types решает все что нужно(конверсия аргументов происходит сама по себе, а требования сразу заставляют думать о том какие данные).