Comments 103
Типа, тайпхинтинг, конечно, крут, но он замедляет всё в 100500 раз.
Я хотел показать каким образом скалярный тайпхинт может привести к ускорению. В конце ответа я написал: «код может ускорится при использовании скалярных тайпхинтов, но в среднем общая производительность останется такой же».
Разумеется синтетика имеет мало общего с реальным приложением в продакшене.
function foo(int $bar)
{
}
, то тогда в неё нельзя передать значение, которое не конвертируется в int строгим образом. Т.е. foo(«abc») приведёт к TypeError. Таким образом да, это таки тайпхинт, а не приведение к int.Я замеряю время, которое тратится на отработку функции целиком, а не только её вызова.
Суть в том, что при наличии скалярного тайпхинта, значение аргумент будет преобразовано в требуемый строгим образом и далее это может привести к ускорению кода внутри функции поскольку в этом случае исчезает type juggling.
Скалярный тайпхинт таки отличается от приведения типа тем, что при тайпхинте значение аргумента не будет насильно приводится к требуемому.
Например, при вышеописанном объявлении функции корректными будут вызовы:
foo(123)
, foo("123")
, foo("12.3e1")
(последние 2 допустимы, если не указан declare(strict_types=1)
), но некорректными (при которых будет выброшено исключение): foo(null)
, foo("123abc")
(внезапно!), foo("abc")
, foo([])
, foo(new stdClass)
,…В то же время если заменить скалярный тайпхинт на приведение типа перед циклом, то тогда все перечисленные выше варианты станут а) допустимыми, б) приведение типа отработает во всех случаях.
Вы либо невнимательно читали, либо неправильно поняли. Скалярный тайпхинт может приводить к ускорению кода так как при использовании оного уменьшается количество неявных приведений типов.
if (!is_numeric($x) || $x != (int) $x) {
throw new TypeError(/* ... */);
}
$x = (int) $x;
То же самое можно сказать и про объекты:
if (!$x instanceof SomeClass) {
throw new TypeError(/* ... */);
}
И не более.
И да, вы правы: тайпхинты нужны для валидации типов аргументов. И не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.
Переводим тест Мандельброта на C# и получаем на настольном ПК для 100 000 итераций
PHP Elapsed 46.472
PHP 7.0.18 (cli) (built: Apr 11 2017 16:35:10) ( NTS )
C# Elapsed 0,99 s
.NET 4.0
С ассемблером тест проводили?
C# может играть в той же нише веб-сервисов, что и PHP — они конкуренты, а асм тут не конкурент.
Конечно, правильнее было еще сравнить потребляемую память: PHP — 7Mb, C# — 7.8Mb
На этом тесте паритет, надо смотреть реальные задачи. Но в целом — для бомжатников — где 1000 сайтов на одном сервере, PHP будет в выигрыше.
Какие уж тут конкуренты :)
Платформа MS полумёртвая и доля её продолжает снижаться каждый месяц. За последний год она упала на 0,6%.
2. вы в реальной жизни, на болиде «формула 1» ездите, надеюсь? (а то иначе дуализм какой-то получается)
5.0.5— зачем?
5.1.6
5.2.17
5.3.29
5.4.45
5.5.38
Really, нет никаких причин тестировать и использовать старые версии. Переход на PHP 7.1 практически бесплатный для любого проекта.
Поддержка брошена. Но сайт был работающим, пока админы не решили обновить РНР с 5.5 до 7.
Пришлось объяснять начальству, почему оно поломалось…
А апдейт джумлы на 3.5 штатными средствами не предусмотрен. Даже через промежуточные версии.
Сайт — он не для того, чтобы удовлетворять потребности программиста, ответственного за него, в изучении новых технологий.
Сайт достался от предшественника.
Joomla 1.7.2
Ощущение что изначальная идея использования джумлы как-раз «удовлетворяла потребности программиста, ответственного за него, в изучении новых технологий» вместо «нечто максимально живучее для варианта „работает — не трожь“ ».
Ну да ладно, в любом случае глубоко соболезную горю тащить это необновляемое легаси.
Причем совсем не бесплатный.
Особенно в части проектов завязанных на старые кодовые базы и расширения к пхп.
Например, php-gearman отлично сегфолтится под 7-ку, тогда как под 5.5 работал.
Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?
p.s. когда я слышу о производтельности php я сразу напоминаю, что очень многие программисты активно используют массивы со строковым ключом как идентификатор поля в своей универсальной структуре (вместо числового ключа, с определенным заранее дефайном, и это я молчу про поддержку классов или, например, использование кортежей), скорость выборки элементов в таком массиве уже не будет зависеть от версии php так сильно?
$t1=microtime(true);
$m=[];
// fill array with random keys, 3chars len each with 0..255 char code
$mlen=(256*256*256)/16; // size of array, part of possble amount of keys to test key missing
for($i=$mlen;$i>0;$i--)
$m[chr(rand(0,255)).chr(rand(0,255)).chr(rand(0,255))]=true;
$t2=microtime(true);
// count miss
$missed=0;
for($a=0;$a<255;$a++)
for($b=0;$b<255;$b++)
for($c=0;$c<255;$c++)
if(!isset($m[chr($a).chr($b).chr($c)]))
$missed++;
$t3=microtime(true);
echo 'filling: '.number_format($t2-$t1,6,'.','').', counting: '.number_format($t3-$t2,6,'.','').PHP_EOL;
PHP 7.1.1 (cli) (built: Jan 18 2017 18:38:28) ( NTS MSVC14 (Visual C++ 2015) x64 )
filling: 1.043060, counting: 8.288474
PHP 5.5.14 (cli) (built: Jun 25 2014 12:41:10)
filling: 2.028116, counting: 13.588777
function rand(min, max)
{
return Math.floor(Math.random() * (max - min)) + min;
}
var nl= require('os').EOL;
var t1=new Date().getTime()/1000;
var m=[];
// fill array with random keys, 3chars len each with 0..255 char code
var mlen=(256*256*256)/16; // size of array, part of possble amount of keys to test key missing
for(var i=mlen;i>0;i--)
m[String.fromCharCode(rand(0,255))+String.fromCharCode(rand(0,255))+String.fromCharCode(rand(0,255))]=true;
var t2=new Date().getTime()/1000;
// count miss
var missed=0;
for(var a=0;a<255;a++)
for(var b=0;b<255;b++)
for(var c=0;c<255;c++)
if(undefined===m[String.fromCharCode(a)+String.fromCharCode(b)+String.fromCharCode(c)])
missed++;
var t3=new Date().getTime()/1000;
console.log('filling: '+(t2-t1)+', counting: '+(t3-t2)+nl);
x86 — v6.10.2
filling: 1.5170001983642578, counting: 15.236999988555908
x64 — v6.10.2
filling: 1.7149999141693115, counting: 18.02999997138977
а теперь внимание, шок (у меня лежала старая версия от 2015 года)
x64 — v0.12.7
filling: 1.5099999904632568, counting: 7.805999994277954
даже не знаю что сказать!
а теперь внимание, шок (у меня лежала старая версия от 2015 года)Этот, немного странноватый, тест наверное единственный случай когда старая нода оказалась быстрее, так как в реальном коде все наоборот.
Причешем немного код на php, и добавим 2 missed счетчика, чтобы была интрига у кого рандомайзер лучше:
<?
$t1 = microtime(true);
$m = [];
// fill array with random keys, 3chars len each with 0..255 char code
$mlen = (256 * 256 * 256) / 16; // size of array, part of possble amount of keys to test key missing
for ($i = $mlen; $i > 0; $i--)
$m[chr(rand(0, 255)).chr(rand(0, 255)).chr(rand(0, 255))] = true;
$t2 = microtime(true);
// count miss
$missed = 0;
$missed2 = 0;
for ($a = 0; $a < 255; $a++)
for ($b = 0; $b < 255; $b++)
for ($c = 0; $c < 255; $c++)
if (!isset($m[chr($a).chr($b).chr($c)]))
if (rand(0, 2) % 2 == 0)
$missed++;
else
$missed2++;
$t3 = microtime(true);
echo 'filling: ' . number_format($t2 - $t1, 6, '.', '') * 1000 . 'ms' . PHP_EOL;
echo 'counting: ' . number_format($t3 - $t2, 6, '.', '') * 1000 . 'ms' . PHP_EOL;
echo PHP_EOL . $missed . '; ' . $missed2 . '; ';
В js коде (вдруг кому интересно):
1. В функция rand не хватает «min + 1»
2. Для подобных целей вместо ассоциативного массива нужно использовать Map
3. Проверять на отсутствие значения лучше так «if (!arr[key])»
4. fromCharCode можно в краткой форме записать «String.fromCharCode(rand(0, 255), rand(0, 255), rand(0, 255))»
5. В начале всех js файлов лучше писать 'use strict'; — избавит от множества проблем.
6. Для вычисления времени выполнения удобно использовать «console.time('metka')», хотя есть и более точный вариант «performance.now()»
Переписанный пример на js:
'use strict';
function rand(min, max) {
return Math.floor(Math.random() * (max - min + 1)) + min;
}
console.time('filling')
var m = new Map();
// fill array with random keys, 3chars len each with 0..255 char code
var mlen = (256 * 256 * 256) / 16; // size of array, part of possble amount of keys to test key missing
for (var i = mlen; i > 0; i--) {
m.set(String.fromCharCode(rand(0, 255), rand(0, 255), rand(0, 255)), true);
}
console.timeEnd('filling')
console.time('counting')
// count miss
var missed = 0;
var missed2 = 0;
for (var a = 0; a < 255; a++) {
for (var b = 0; b < 255; b++) {
for (var c = 0; c < 255; c++) {
if (!m.get(String.fromCharCode(a, b, c))) {
if (rand(0, 2) % 2 === 0)
missed++;
else
missed2++;
}
}
}
}
console.timeEnd('counting')
//console.log(`\n${missed}; ${missed2}; `);
console.log('\n' + missed + '; ' + missed2 + ';'); // for node v0.12.7
И, соответственно, результат:
PHP 7.1.4 (cli):
>php test.php
filling: 788.352ms
counting: 7672.947ms
10387458; 5189704;
node v0.12.7:
>node test.js
filling: 616ms
counting: 7304ms
10393087; 5195409;
node v7.9.0:
>node test.js
filling: 533.590ms
counting: 6663.210ms
10386734; 5190004;
Результат уже более предсказуемый, если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php, или вычисления какие с этими данными.
Не, ну это не совсем честно. Вы ведь код под ноду оптимизировали?
Что не честно? Вы процитировали цитату из части про «если бы», о чем речь?
Я вообще ничего не оптимизировала, я написала как будет правильно под ноду.
Использовались более эффективные конструкции языка.
Далее было сказано, что " если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php". Было такое утверждение? Было.
Данное утверждение логически верно. Я не могу сказать что вы ошибаетесь, или врете.
Всё так. Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.
Они тоже не очень удачно спроектированы, и я думаю что даже с ними нода будет в выигрыше. Но тем не менее если уж сравнивать код на разных языках, то стоит использовать оптимальные конструкции для каждого языка, даже если они несколько отличаются.
А значит _честно_ будет использовать не числовые массивы, а именно классы из SPL.
Двусвязный список или ФиксМассив, не суть.
Мне вот интересно, это я действительно настолько непонятно выразился что нужно было оценивать человека, а не комментарий, причем массово, или это оппоненты настолько плохо знают язык (в статье про пхп прошу заметить, не про ноду), что не пользуются SPL и не поняли моего высказывания?
Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.
Любой кто когда либо работал с SPL знает, что они ужасны.
Далее было сказано, что " если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php". Было такое утверждение? Было.
Разницы между 7672.947ms и 6663.210ms можно сказать вообще нет, поэтому я написала про обычные массивы или про вычисление каких-нибудь данных, где разница была бы заметнее.
Вы переписали код ноды так, как более правильно писать под ноду. Было? Было.
Я переписала код так, как правильно писать под js, ведь тянуть php практики в js не правильно по многим причинам, и это ни для кого ни секрет. «new Map» вместо ассоциативных массивов рекомендуют использовать все, в том числе и создатели node. Да если уж на то пошло, вообще использовать es6 рекомендуют по полной.
Если у php есть что-то подобное, то никто не запрещает вам переписать php-пример.
Но именно [] в php7 и есть лучший выбор, потому что на него был сделан основной упор оптимизаций по сравнению с php5.
Как только мы об этом узнали, мы перевели все сайты на php7-fpm (давно, еще в бете) и отлично он держит ~2.652.376 хитов в день. На ноду переходить вообще не вижу смысла, но это не отменяет того факта, что на js надо писать правильно.
И хотя я знала, что кто-то обязательно придерется к Map, я всё-таки сделала упор на new Map только по той причине, что он тут правильнее по смыслу, es6 все дела. Можно было бы и без него, достаточно всего 1 строчки кода в оригинальном примере после цикла:
m = m.slice();
И код бы ускорился в 2 раза, и так же бы обогнал php-версию, без каких-либо новых структур данных
Вы бы тоже сказали, что это читерство? Хотя все кто пишут на js знают, что если уж вы начали массив заполнять ассоциативными данными, то это будет череда скрытых классов, которые работают крайне не эффективно и после заполнения надо слить их в новый единый объект. А оправдывать тем фактом, что якобы не все про это знают, не говорит о скорости языка ни как.
А значит _честно_ будет использовать не числовые массивы, а именно классы из SPL. Двусвязный список или ФиксМассив, не суть.
Мне вот интересно, это я действительно настолько непонятно выразился
Вместо рассуждений, могли бы просто взять и привести правильный пример. Но у вас не получилось бы, потому что в SPL ни один из них не делает то, что нужно в данном случае. Или если делает, то очень заморочено, и нужно писать обвязку. И всё равно это было бы медленнее, чем [] в php7.
$ node map.js
filling: 637.137ms
counting: 7916.720ms
10388534; 5187885;
$ node set.js
filling: 502.317ms
counting: 7290.966ms
10384428; 5192356;
И в данной задаче сначала заполняются случайные ключи хэшмепа и им присваивается значение true (которое не используется, потому что оно не нужно). А потом проверяется наличие ключей в этом хэшмепе.
То есть обе операции которые используются во множествах.
Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?
шо, опять? ©
Мало того, неплохой нормой становится http сервер тоже на php (само собой прикрытые nginx proxy), это очень часто заметно поднимает производительность итогового результата (за счет возможности повторно не инициализировать переменные на каждый запрос).
Логичный вопрос — смена версии даст сильный прирост или нет?
Логичный вопрос — смена версии даст сильный прирост или нет?
для вебсокетного сервиса на PHP по скорости вряд ли, по памяти точно
Шутки не понял, если у меня сервер на php то мне будет сложно правильно использовать сторонние (но не невозможно само собой), а значит реализация именно серверной части с обслуживанием подключений и пользователей будет на php, гугл выдает с десяток реализаций.
да не было никакой шутки
да можно, решения есть, но при поддержке такого решения постоянно придется решать проблемы, которые давно уже решены.
php-шнику на том же nodejs ws-сервис сделать не сложнее чем на php, если не проще. и экосистема там богаче в этом плане, это его ниша.
Буквально недавно решал задачу, как в пределах одного процесса заставить эффективно по ресурсам работать websocket (а потом и push http) сервер и асинхронную загрузку файлов по http (позже и подключение к сторонним websocket).
на nodejs у меня не возникнет никаких проблем в реализации этого?
Используя готовые решения — websocket сервер на socket (расширение php) и асинхронную загрузку curl_multi_… красивого решения не получается — у них разные механизмы организации цикла
p.s.у каждого свой метод ожидания события на сокете, нет метода, который позволил бы ждать события в обоих библиотеках, можно только проверить их наличие по отдельности, т.е. либо 100% нагрузка в пустом цикле либо вставка слипов и таймаутов, которые заметно замедлят работу при нагрузке
предположу, чтобы подобное реализовать, потребуется реализация HTTP на PHP и работа с удаленным сервером через сокет. дальше, наверное, потребуется асинхронная работа с диском, БД…
на nodejs с этим проблем не будет
можно использовать Go, но это тема для холивара )
Не хватает в таблице строки с каким нибудь другим языком (java например или go), что бы иметь общее представление о производительности php7.
На что только люди не пойдут чтобы не учить нормальный язык программирования...
Мог бы ответить вам по существу, но не на такой хамский выпад, конечно.
Просто товарищи за меня додумали что я якобы критикую PHP. Я полностью с вами согласен — в рейтинге «самый простой язык для бэкенда» PHP будет в топе, и очень часто этого достаточно. Простота и отсутствие необходимости обучаться — это вещи в данном случае взаимосвязанные, на что я и указал.
А я бы с удовольствием почитал ваши доводы. Ну то есть тема, конечно, обсосанная до невозможности, но холивар на то и холивар.
Перед каждой переменной нужно ставить знак доллара. Программисты правда к этому уже настолько привыкли, что даже не замечают насколько это странно .
- Доступ до полей класса производится через ->, а не через точку. Программисты правда к этому уже настолько привыкли, что даже не замечают насколько это странно — печатать два символа вместо одного.
В рамках холивора, вот два объективных недостатка, которых легко могло бы и не быть.
Ну хватит уже, ну правда. На эти вопросы уже раз 500 давали ответы и на хабре и везде где только можно.
Ну да, ответы обычно именно такие — в стиле — я пишу на PHP и эти недостатки меня совершенно не беспокоят. Это не значит, что недостатков нет.
Это все недостатки которые вас беспокоят или есть еще что-то?
Есть, конечно. У всех языков программирования есть недостатки. Эти конкретные — просто хороший пример. Очевидно они есть. Очевидно это недостатки. Отсутствие конкарренси можно оправдать например тем, что php не решает задач в которых она нужна. А тут — просто недостаки, без оправданий.
Я не уходил от ответа. Меня спросили есть ли ещё недостатки php, которые меня беспокоят, я ответил, что есть, но сказать хотел именно о тех недостатках, о которых сказал.
Что касается языков — Lua и Perl я не владею. С — успешный язык, недостатков в нём много, они расписаны много где. Но я про конкретику из PHP вообще.
И снова как и в предыдуший раз "PHP плохой потому что плохой.
На случай, если вы невнимательно читали в прошлый раз, я дам выжимку из того, что я говорил. У php как минимум 2 недостатка.
- Нужно писать доллар перед переменными, хотя без этого можно было бы легко обойтись.
- Для доступа к полям класса нужно использовать -> а не точку. 2 символа вместо одного.
Вы почему-то в этом тексте видите буквы, которые складываются в "php плохой". Ну, бывает.
Да бесполезно с вами разаговаривать, вы не владеете информацией более чем полностью.
Действительно, ведь в php давно уже не надо ставить $ перед переменными и доступ для полей не через ->, да? :)
Php плохой,
Я так и сказал? Тогда цитируйте, не стесняйтесь.
- Это пришло если что из Perl. Потому что php писался под впечатлением от perl, а там то же переменные начинаются с $.
- Это отдельная операция, называется конкатенация строк. В начале, в самой первой версии php, ООП там вообще не было. По-этому доступ к членам класа там не то что не был продуман, о нём вообще не думали
Ну да, объективные недостатки php продиктованы тяжёлым наследием прошлого. От этого они не перестают быть недостатками.
И опять же, в предыдущем комменте я не просто так спросил про Lua. Представляете, в Lua конкатенация строк осуществялется (барабанная дробь) аж целыми двумя точкам '..'. Наверно теперь Lua для вас ну просто "ублюдок" какой-то?
Да нет, как конкатенировать строки не очень важно. Важно как прописываются операции, которые приходится делать постоянно. Как делается в Lua доступ к полям?
Использование $ перед переменной не большая цена, к тому же это фича, двойной знак — переход к переменной по имени в переменной. Мало того, символ $ сразу говорит что мы имеем дело с идентификатором-переменной, без необходимости взгляду анализировать окружение (когда ищешь беглым взглядом что-либо, переменные сразу бросаются в глаза).
И вообще, короткая запись не всегда благо, лучше лишних символов добавить если читаемость повысится.
На си и си++ тоже есть '->' и '.', собственно первое — переход к полю объекта по ссылке, второе, к самому объекту. Это вполне в духе php — объекты там все по ссылке.
В си и си++ есть -> потому что точка занята другим похожим действием. В php точка посажена на конкатенацию, которая происходит существенно реже, чем обращение к полю объекта.
Использование $ перед переменной не большая цена
Я и говорю, программисты уже не замечают, насколько это странно.
Мало того, символ $ сразу говорит что мы имеем дело с идентификатором-переменной, без необходимости взгляду анализировать окружение
Странно, что эту крайне важную фичу не засунули в языки, которые появились позже php :). Вы не пользуетесь подсветкой кода?
И вообще, короткая запись не всегда благо, лучше лишних символов добавить если читаемость повысится.
Не всегда. Но это не тот случай.
Но это одна из тех вещей которые привели пхп к его нынешней популярности.
И поскольку слабая динамическая типиизация это объективная реальность, то скажите мне, на что вы предлагаете заменить конкатенацию? Если точка будет занята, то что же у нас будет?
Привычный плюс? Тогда что мы получим на выходе если у нас будет $x = '2' + '2';?
Я пришел в пхп во времена пхп4. И меня тоже бесили эти странности языка (доллар не бесил).
Тогда еще по факту не было ООП в пхп (оно и сейчас еще не очень распространено, если по честному). Но все равно раздражало.
Однако положа руку на сердце — плюс тут будет еще страшнее.
И да, если в пхп4 (четыре Карл!) доступ к членам класса был еще не очень популярным, то что мы хотим от первых версий.
Странно, да.
Непривычно, да.
Но логично.
И к недостаткам языка оно явно не относится.
Недостаток языка это хаос в функциях.
Недостаток языка это то что все еще нормальная типизация скаляров не доступна на многих хостингах (пхп7+ еще недостаточно популярен). Недостатков много. Но в целом они следствие его достоинств, и воспринимаются как данность.
Что до _непривычности_, а это именно непривычность — ну бывает, чё.
Никогда не пробовали писать под 1С?
У меня ушло недели две, чтобы перестать обращать на это внимание.
Ну перевод и перевод.
И у языка 1с есть куча недостатков. Например его предметнориентированность подразумевает неестественные механизмы расширения существующих сущностей. ООП был бы удобнее.
Но русский язык это просто решение. И решение умное, правильное и удачное. Это его сильная сторона да.
Почему русский?
Многие заблуждаются думая что «глупые недопрограммисты ленятся заучивать конструкции». Это не так. Ведь конструкций не много. А правда в том, что предметная область вся на русском. План счетов как называть? Ну ок, это расхожий термин, вызубрим перевод. А что такое Invoice в коде Васи? Что он имел ввиду? У нас ведь не ВЭД. Это счет или накладная?
Или может вообще ТТН? (Я знаю что у большинства терминов есть перевод, но много ли заказчиков их знают? И знаю правильно? Программист должен знать про предметную область больше чем заказчик? Знать все эти явления, суть их, названия, да еще и переводы? Зачем?
Писать if актВыполненныхРабот.проведен then… можно. Но… зачем? Чтобы было привычнее? Все равно не привычно). А их SQL забавен, да. Взял сейчас томик справочника, нашел пример какого-то запроса, и смог понять только после мысленного перевода всех этих «объединить» на join и т.п. А когда имел с этим дело — на работе по русски, дома по английски, и нормально читалось и писалось.
Многабукафф, да.
Еще раз что сказать хотел. Коротко. $x = '2' + '2'; должно давать 4. Так проектировался язык.
И для него это норма. Такие были задачи. В форме данные все нетипизированные, в строках приходят, потом разбираем. Так что в нише пхп слабая динамическая была очень даже.
Сейчас при готовой инфраструктуре оно может и не очень надо. Но инфраструктуры бы не было, если бы не простота…
ПС: я вкурсе что вы не говорили что «пхп говно», я чисто в качестве аргумента что именно ваши недостатки — недостатками не считаю.
А много ли выигрыша от JIT, учитывая, что пхп умирает после каждого запроса в подавляющем большинстве сценариев использования? Или там скомпилированный код будет в opcache сохраняться?
Плюс в реальности довольно много нагрузки приходится на всякие обходы массивов или объектов.
Бутылочным горлышком обычно являются таки СУБД а не пхп. Скорость не везде, но часто вторична, а вот прожорливость по памяти бывает мешает.
Вся беда в том что проекту более 10 лет и перевод на php7 тяжек.
С точки зрения программиста нужно все сжечь и переписать.
А с точки зрения руководителя проекта, просто перейти на новую версию php по возможности и более мощный сервер оплатить. А новые модули, писать на C++ но возможности. А часть вообще планируется под GPU.
Сравнение производительности версий PHP