В этой статье мы рассмотрим результаты нескольких бенчмарков, начиная с PHP 5 и вплоть до экспериментальной JIT-ветки (сейчас в разработке). На момент написания не было известно, появится ли до PHP 8 ещё какая-то основная версия, например PHP 7.2. Но логично предположить, что возможности экспериментальной ветки как минимум будут включены в PHP 8.
C момента своего появления в 1994-м язык PHP радикально изменился. Первые релизы представляли собой просто внешние CGI-программы, которые создавались во многом как личный проект Расмуса Лердорфа. С третьей версии PHP был серьёзно переработан, возникла группа разработчиков языка.
Благодаря расширяемости PHP 3 функциональность языка стремительно разрасталась. Появлялись базовые и дополнительные расширения, которые привносили новые функции в разные сферы: работу с сетью, парсинг, кеширование и поддержку баз данных.
Развивался и сам язык, в него внесли много улучшений. Появилась поддержка объектно ориентированных конструкций, таких как классы, интерфейсы, трейты, замыкания и т. д.
Но многим разработчикам этого было мало. С ростом популярности языка росли и требования к нему со стороны сообщества, в основном связанные с производительностью, масштабируемостью и более экономным потреблением памяти.
Почти 20 лет создатели языка прилагали огромные усилия, чтобы удовлетворять всевозможные требования. Хотя с появлением PHP 3 производительность существенно возросла, сколько-то серьёзные результаты язык смог продемонстрировать только с PHP 4, когда появился движок Zend.
В 2000-м были внедрены новые in-memory компилятор и модель исполнения (executor model). Это позволило вновь сильно поднять производительность PHP, нередко в 5—10 раз. В результате его начали всерьёз рассматривать как инструмент для создания веб-приложений и сайтов. И сегодня PHP достиг высот, которых никто не ожидал от этого языка, когда он появился.
Но взрывной рост популярности PHP лишь привёл к росту требований о повышении производительности. К счастью, у движка Zend прекрасный потенциал для модернизации.
Хотя PHP 5 не стал заметным шагом вперёд и в некоторых случаях был даже медленнее PHP 4, группа разработчиков Zend постоянно оптимизировала движок от релиза к релизу, в результате PHP 5.6 оказался быстрее в 1,5—3 раза.
Но главный рывок произошёл с выходом PHP 7 в декабре 2015-го. Через год была анонсирована версия 7.1, тоже получившая ряд улучшений.
Компилятор PHP JIT и ожидания по улучшению производительности PHP 8
В настоящее время разрабатывается очень многообещающая версия Zend. Она будет основана на версии из релиза 7.1, а когда именно выйдет, пока не объявлено. Так что сейчас это экспериментальная JIT-ветка.
Одна из главных интриг связана с Just-In-Time (JIT) компиляцией. Это методика преобразования кода в другой формат (нативный машинный код) прямо перед выполнением. Цель JIT — повысить скорость работы программ. Посмотрим, смогут ли разработчики сдержать обещание.
Бенчмарк обработки PHP-скриптов
Для этой статьи использовались бенчмарки, измерявшие производительность обработки скриптов на чисто процессорных задачах, т. е. без операций ввода-вывода: обращений к файлам, подключений к сети или базе данных.
Применялись следующие бенчмарки:
- bench.php — находится в папке php-src/Zend исходного дистрибутива PHP.
- micro_bench.php — там же.
- mandelbrot.php
Бенчмарки прогонялись на последних второстепенных релизах основных версий PHP:
- 5.0.5
- 5.1.6
- 5.2.17
- 5.3.29
- 5.4.45
- 5.5.38
- 5.6.28
- 7.0.13
- 7.1.0
- Экспериментальная JIT-ветка
Те же бенчмарки прогонялись и на всех промежуточных релизах, например между 5.3.0 и 5.3.29. Результаты красноречивы: релизы не демонстрировали заметных улучшений производительности. Улучшения отмечались только при переходах между основными версиями, например с PHP 5.4 на PHP 5.5 или с PHP 5.6 на PHP 7.
Это означает, что те же скрипты будут выполняться примерно с одной скоростью и на PHP 5.4.0, и на PHP 5.4.45.
Подробности о настройке хостовой системы, о выполнении конкретных бенчмарков и об интерпретировании результатов можно почитать тут.
Сравнение результатов процессорных бенчмарков
По каждому бенчмарку приведены три значения:
- Время, с: время выполнения (в секундах).
- Относительное изменение, %: изменение времени выполнения по сравнению с предыдущей версией. Если бенчмарк выполнялся быстрее — значение положительное, если медленнее — отрицательное.
- Абсолютное изменение, крат: насколько быстрее выполнялся скрипт по сравнению с PHP 5.0.
Результаты прогона бенчмарков вы можете увидеть в таблице ниже.
(1) Бенчмарк не может выполняться на версиях до 5.3, потому что он использует свойства, которые ещё не были реализованы.
(2) Результаты в этой колонке немного смещены, потому что бенчмарку для работы нужен как минимум PHP 5.3. Их можно взять просто для справки, раз нельзя сравнить с PHP 5.0.
(3) Это модифицированная версия скрипта mandelbrot.php, который выполнялся слишком быстро в версии 7.1.0 в экспериментальной ветке, так что не получалось точно измерить скорость. Поэтому мы внутри скрипта выполняли сто вычислений, а не одно.
Конечно, чисто процессорные бенчмарки не позволяют оценить все аспекты производительности PHP. Данные могут быть нерепрезентативны. Тем не менее на основе этих данных можно сделать выводы:
- PHP 5.1 более чем вдвое быстрее PHP 5.0.
- Версии 5.2 и 5.3 обладают новым набором улучшений, но не таких впечатляющих, как у 5.1.
- Следующий скачок производительности был у версии 5.4.
- Расширение opcache поставлялось с 5.5 и 5.6. Это позволяло повысить производительность за счёт ускорения загрузки кода, когда один и тот же скрипт выполнялся последовательно. Однако opcache не слишком полезно для скриптов, исполняемых в режиме CLI.
- PHP 7.0 — главный прорыв с точки зрения производительности. Движок Zend был полностью переработан, и мы наблюдаем результат этих масштабных изменений.
- В PHP 7.1 в расширении opcache были оптимизированы опкоды, что объясняет скачок производительности по сравнению с 7.0.
- Экспериментальная JIT-ветка демонстрирует очередной скачок производительности. Но в некоторых случаях никакого улучшения нет. Иногда ветка оказывается даже медленнее, потому что компилирование не ускоряет работу кода. Но не будем забывать, что эта фича пока в разработке.
Сопоставление производительности разных версий PHP
PHP 5 гораздо производительнее, чем PHP 4. Движок Zend, лежащий в основе интерпретатора, был полностью переработан (Zend Engine 2), что открыло дорогу дальнейшим улучшениям. Здесь мы не будем освещать все различия между PHP 4 и PHP 5, вкратце пройдёмся лишь по вещам, внедрённым после PHP 5.0.
Ниже перечислены только те изменения, которые затронули ядро PHP. Более подробный список нововведений и изменений: PHP 5 и PHP 7.
PHP 5.1
- Скомпилированные переменные
- Специализированный исполнитель (Specialized executor)
- Кеш real-path
- Ускоренная обработка выражения
switch() - Ускоренные функции массивов
- Ускоренное извлечение переменных
- Ускоренный вызов «волшебных» методов
PHP 5.2
- Новый диспетчер памяти
- Оптимизированное копирование массивов/хеш-таблиц
- Оптимизированные выражения
require_once()иinclude_once() - Небольшие оптимизации специфических внутренних функций
- Улучшенное компилирование HEREDOC и компилирование интерполированных строк
PHP 5.3
- Сегментированный стек VM
- Бесстековая VM
- Замена констант в ходе компилирования
- Ленивая инициализация таблицы символов
- Улучшение real-path кеша
- Улучшение скорости runtime и потребления памяти
- Ускоренный парсинг языка
- Улучшение размера двоичных PHP-файлов и запуска кода (code startup)
PHP 5.4
- Отложенное размещение хеш-таблицы
- Константные таблицы (Constant tables)
- Рантаймовые кеши привязки (binding caches)
- Интернированные строки (Interned Strings)
- Улучшенный уровень вывода (output layer)
- Улучшена производительность тернарных операторов при использовании массивов
PHP 5.5
- Улучшено соглашение о вызове (calling convention) виртуальной машины
- Интеграция OPcache
- Другие оптимизации движка Zend
PHP 5.6
- Оптимизирована обработка пустых строк, минимизирована необходимость в размещении новых пустых значений
PHP 7 vs. PHP 5.6
Большинство из этих улучшений относятся к движку Zend:
- Рефакторинг основных структур данных
- Улучшена конвенция вызова виртуальной машины
- Новый API парсинга параметров
- Новый диспетчер памяти
- Многочисленные улучшения исполнителя виртуальной машины
- Существенно уменьшено использование памяти
- Улучшены функции
__call()и__callStatic() - Улучшена конкатенация строк
- Улучшен поиск символов в строках
PHP 7.1, улучшения производительности
- Новый оптимизационный фреймворк на базе SSA (встроен в opcache)
- Глобальная оптимизация байткода PHP на основе выведения типов (type inference)
- Высокоспециализированные обработчики опкодов виртуальной машины
Свойства PHP 8 или PHP 7.2, экспериментальная JIT-ветка
- Компилирование Just-In-Time
Как измерялась производительность
Прогон бенчмарков был чуть более сложным процессом, чем запуск Unix-команды time, и проходил в несколько этапов:
Настройка системы
С сделал выделенную систему с такими характеристиками:
- VPS с одним виртуальным ядром, 2,4 ГГц, 2 Гб памяти и два SSD drives — один для ОС, второй для хранения исходных файлов PHP, бинарных файлов и записи отчётов.
- ОС Debian Wheezy 3.2.82-1
- Компилятор Gnu C 4.9.2-10 (дистрибутив Debian Jessie).
Хотя система поставлялась с компилятором Gnu C 4.7.2, пришлось поставить более свежую версию: экспериментальная JIT-ветка должна компилироваться с помощью Gnu C 4.8 и выше.
Компилирование исходного кода
Перед сборкой полных дистрибутивов был запущен скрипт configure со следующими параметрами:
--prefix=/usr/local/php
--disable-debug
--disable-phpdbg
--enable-mysqlnd
--enable-bcmath
--with-bz2=/usr
--enable-calendar
--with-curl
--enable-exif
--enable-fpm
--with-freetype-dir
--enable-ftp
--with-gd
--enable-gd-jis-conv
--enable-gd-native-ttf
--with-gettext=/usr
--with-gmp
--with-iconv
--enable-intl
--with-jpeg-dir
--enable-mbstring
--with-mcrypt
--with-openssl
--enable-pcntl
--with-pdo-mysql=mysqlnd
--with-png-dir
--with-recode=/usr
--enable-shmop
--enable-soap
--enable-sockets
--enable-sysvmsg
--enable-sysvsem
--enable-sysvshm
--enable-wddx
--with-xmlrpc
--with-xsl
--with-zlib=/usr
--enable-zip
--with-mysqli=mysqlndКонечно, я компилировал более старые версии, некоторые параметры требовалось отключить или заменить другими. Также не все расширения были доступны или могли быть скомпилированы.
Запуск бенчмарков
Каждый бенчмарк запускался с помощью PHP CLI (Command-Line Interface) через специальный скрипт, который делал следующее:
1) С помощью функции microtime() на лету модифицировал скрипт, чтобы изнутри измерять время его выполнения. После модифицирования скрипт выглядел так:
<?php
$__start__ = microtime( true );
/***
Здесь исходный код бенчмарка
***/
fprintf( STDERR, microtime( true ) - $__start__);
?> Это делалось для того, чтобы обеспечить стабильность измерений скрипта изнутри, без изменения его поведения.
2) Далее шли два сухих прогона, чтобы исполняемые PHP-файлы и содержимое скрипта бенчмарка оказались в кеше ОС.
3) Скрипт выполнялся пять раз, сохранялись минимальное, максимальное и среднее время выполнения. В этой статье представлены только средние значения — «время выполнения скрипта».
Использовались такие настройки в php.ini:
engine = On
short_open_tag = Off
realpath_cache_size = 2M
max_execution_time = 86400
memory_limit = 1024M
error_reporting = 0
display_errors = 0
display_startup_errors = 0
log_errors = 0
default_charset = "UTF-8"
[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.optimization_level=-1
opcache.fast_shutdown=1
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.use_cwd=1
opcache.max_accelerated_files=100000
opcache.max_wasted_percentage=5
opcache.memory_consumption=128
opcache.consistency_checks=0
opcache.huge_code_pages=1
// PHP 8/Next only
opcache.jit=35
opcache.jit_buffer_size=32MИнтерпретирование результатов
Длительность выполнения измерялась с помощью Unix-команды time. Пример выходных данных:
$ time php bench.php
real: 0m1.96s
user: 0m1.912s
sys: 0m0.044sЗначение real — это время от вызова команды до её прерывания (пока не происходит возврата к командной строке).
Значение user — время, потраченное на выполнение пользовательского кода (в данном случае — исполняемого PHP-файла).
Значение sys — время, потраченное на выполнение кода ОС (kernel). Это значение должно быть минимальным, но может оказаться сильно больше представленного, если ваш код обращается, например, к медленным устройствам. Также на величину значения способна повлиять высокая загруженность ОС.
На системах в состоянии ожидания суммарное значение user + sys должно быть очень близко к real. В приведённом выше примере: user + sys = 1,956 с, real = 1,960 с. Разница в 0,004 с связана не с нашим процессом, а с разными задачами ОС, например с диспетчеризацией.
Тот же скрипт был выполнен на высоконагруженной ОС при параллельном компилировании тремя разными PHP-версиями:
$ time php bench.php
real: 0m7.812s
user: 0m2.02s
sys: 0m0.101sКак видите, уровень нагрузки сильно влияет на время выполнения (возможно, и на системное время). Поэтому я добавил в бенчмарк ещё одно значение — overhead операционной системы. Это разница между полным временем выполнения (elapsed time) и суммой пользовательского и системного времени.
Я удостоверился, чтобы во время прогона бенчмарков это значение в течение 99 % времени было меньше 100 миллисекунд, даже когда выполнение скриптов занимало десятки секунд.
Спасибо Дмитрию Стогову и всей команде разработки PHP
Эта статья писалась при активной помощи Дмитрия Стогова. Он прояснил ряд моментов и рецензировал представленную здесь информацию.
Дмитрий был разработчиком расширения Turck MMCache, которое со времён PHP 4 может использоваться для кеширования PHP-опкодов в совместно используемой памяти. После этого Дмитрий начал работать над Zend, чем и занимается по сей день.
Также он когда-то инициировал создание PHPNG — того, что позднее превратилось в PHP 7. В работе над этой и последующими версиями с Дмитрием сотрудничали Никита Попов и Синьчэнь Хуэй (Xinchen Hui).
В создание PHP 5 внесли большой вклад Энди Гутманс, Зеев Сураски и Стас Малышев. Многих других разработчиков я не стану здесь перечислять, чтобы не загромождать статью.
Специальное благодарственное видео для всех, кто помогал развивать PHP
В 2016-м исполнился 21 год со дня появления PHP — 8 июня 1995 г.
Чтобы отдать должное всем, кто так или иначе внёс свой вклад в развитие PHP, Питер Кокот с помощью Gource создал анимационное видео. В нём рассказывается о развитии ключевых модулей PHP в течение всей жизни языка.
Питер Кокот хорошо известен в PHP-сообществе. Он основал в Facebook PHP Group, крупнейшую группу, посвящённую отдельному языку программирования. В ней состоят более 140 тыс. участников и 22 модератора. Создатель PHP Расмус Лердорф сказал: «В мире PHP ничего не происходит без движения сообщества». Надеюсь, эти слова будут вдохновлять вас.
Если вы не можете помочь развитию PHP с помощью написания кода на С, то можете выкладывать свои PHP-разработки на GitHub, PHP Classes, Packagist — куда угодно. Чем больше мест, где мы будем делиться друг с другом наработками, тем лучше.
Заключение
Цель статьи — дать представление о производительности разных версий PHP, начиная с 5.0 и заканчивая свежайшей экспериментальной версией. Тестирование выполнялось с помощью известных бенчмарков. Также в статье приведён список улучшений, повысивших производительность различных версий PHP.
Комментарии (103)
gro
18.04.2017 16:18-4Гораздо интереснее сравнивать новые фичи.
Типа, тайпхинтинг, конечно, крут, но он замедляет всё в 100500 раз.
sumanai
18.04.2017 16:24+5Типа, тайпхинтинг, конечно, крут, но он замедляет всё в 100500 раз.
Тогда сравнивать нужно с ручной реализацией того же самого старыми методами. И я думаю нативная выйдет быстрее.
vladqa
18.04.2017 18:26А можно, пожалуйста, ссылку на какой-нибудь бенчмарк или слова разработчиков PHP? Иначе это какое-то голословное утверждение.
bashkarev
19.04.2017 21:42Вот здесь, Дмитрий рассказывает как работает тайпхинтинг.
vladqa
19.04.2017 22:28Что и требовалось доказать: никакого замедления в 100500 раз нет. Поскольку все происходит в рантайме, то конечно есть накладные расходы небольшие, это и так достаточно очевидно. Но так бы мы писали эти же проверки и касты самостоятельно.
xotey83
18.04.2017 18:41+2Вы не разбираетесь в матчасти. Тайпхинтинг как минимум не замедляет. И даже отчасти ускоряет.
xotey83
18.04.2017 18:47Лень описывать всё по-новой. Просто прочитайте мой ответ на тостере по поводу скалярных тайпхинтов: https://toster.ru/answer?answer_id=937289
qRoC
19.04.2017 13:41Ваш пример высосан из пальца:
1) Функция заранее принимает аргумент не того типа;
2) Аргумент используется 10000000 раз(кейш больше похож на замер времени преобразования типа).
3) Что бы замерить производительность, нужно вызывать foo($x), foo(int $x), foo($x) {is_int($x} N раз.
В реальных кейсах тайп хинтинг реально замедляет приложение, но это настолько незаметно, что не стоит обращать внимание.xotey83
19.04.2017 14:23Верно. Высосан из пальца, потому что это синтетический пример, о чём было сказано в начале.
Я хотел показать каким образом скалярный тайпхинт может привести к ускорению. В конце ответа я написал: «код может ускорится при использовании скалярных тайпхинтов, но в среднем общая производительность останется такой же».
Разумеется синтетика имеет мало общего с реальным приложением в продакшене.qRoC
19.04.2017 14:33Так где в Ваших тестах тайп хинтинг? Вы замеряете время преобразования string -> int. С таким же успехом до цикла можно прописать $x = (int)$x;. Тайп хинтинг не об этом. Ваш код, это скорей демонстрация возможных ошибок разработчика, но не как тест производительности.
xotey83
19.04.2017 15:15Тайпхинтинг в объявлении аргументов функции. И это таки тайпхинт, а не тупое насильное преобразование string -> int. Поскольку функция объявлена со скалярным тайпхинтом,
, то тогда в неё нельзя передать значение, которое не конвертируется в int строгим образом. Т.е. foo(«abc») приведёт к TypeError. Таким образом да, это таки тайпхинт, а не приведение к int.function foo(int $bar) { }
Я замеряю время, которое тратится на отработку функции целиком, а не только её вызова.
Суть в том, что при наличии скалярного тайпхинта, значение аргумент будет преобразовано в требуемый строгим образом и далее это может привести к ускорению кода внутри функции поскольку в этом случае исчезает type juggling.
Скалярный тайпхинт таки отличается от приведения типа тем, что при тайпхинте значение аргумента не будет насильно приводится к требуемому.
Например, при вышеописанном объявлении функции корректными будут вызовы:foo(123),foo("123"),foo("12.3e1")(последние 2 допустимы, если не указанdeclare(strict_types=1)), но некорректными (при которых будет выброшено исключение):foo(null),foo("123abc")(внезапно!),foo("abc"),foo([]),foo(new stdClass),…
В то же время если заменить скалярный тайпхинт на приведение типа перед циклом, то тогда все перечисленные выше варианты станут а) допустимыми, б) приведение типа отработает во всех случаях.
Вы либо невнимательно читали, либо неправильно поняли. Скалярный тайпхинт может приводить к ускорению кода так как при использовании оного уменьшается количество неявных приведений типов.qRoC
19.04.2017 15:27Вы либо невнимательно читали, либо неправильно поняли. Скалярный тайпхинт может приводить к ускорению кода так как при использовании оного уменьшается количество неявных приведений типов.
$x = (int)$x
тоже уменьшает количество неявных приведений.
По сути не в strict режиме аналог:
if (!is_int($x)) { $x = (int)$x; }
В strict тоже самое, но ошибку выбрасываем.
И не более.qRoC
19.04.2017 15:34Скалярный тайпхинт таки отличается от приведения типа
Да, отличается. Тем что «Typehint» это контроль типа. Т.е. тот if который в коде выше. А вот strict_types это поведение — приведение типа или ошибка.
при тайпхинте значение аргумента не будет насильно приводится к требуемому.
Как раз таки оно или будет приводится или будет выдавать ошибку. Зависит от strict_types.
xotey83
19.04.2017 15:41Не в стрикт режиме аналог это
if (!is_numeric($x) || $x != (int) $x) { throw new TypeError(/* ... */); } $x = (int) $x;
То же самое можно сказать и про объекты:if (!$x instanceof SomeClass) { throw new TypeError(/* ... */); }
И не более.
И да, вы правы: тайпхинты нужны для валидации типов аргументов. И не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.qRoC
19.04.2017 15:54Не в стрикт режиме аналог это
Ну в правильности спорить не буду, хотел просто сказать что это, по сути, условие, и не более.
Разница в том, что тайпхинт работает таки быстрее, чем «аналоги». И не более.
Тут скорей дело в том, что интерпретатор не сильно пытается проанализировать код.
Ну, а вообще мы перевели диалог о производительности с typehint и без, на typehint против if. А здесь я остаюсь при своём мнении — оверхед минимальный, качество кода — заметно выше, а значит нужно использовать.
prgrant
18.04.2017 16:38А некоторые уверены, что PHP умрет… Впрочем как всегда ))
OnYourLips
19.04.2017 09:21+2Умирает, и будет тысячи раз умирать. Чем будет популярней, тем будет больше умирать.
Концепция жизненного цикла приложения такая, за исключением небольшое количества асинхронных приложений.
Вы просто неправильно поняли фразу.
ACPrikh
19.04.2017 12:47Наоборот. Удивительное развитие. То есть удивительно тем, что на насыщение скорость не выходит. Сколько же там косяков или принципиальных лагов, если он так постоянно и существенно совершенствуется? Впечатление, что он изначально был написан с бодуна левой ногой по-французски.
sumanai
19.04.2017 17:01Впечатление, что он изначально был написан с бодуна левой ногой по-французски.
Обижаете. На иврите.
Siemargl
18.04.2017 17:05-3Ок, как раз в пару моей вчерашней статье из которой следует — «по возможности не используйте интерпретаторы!».
Переводим тест Мандельброта на 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
grSereger
18.04.2017 20:55-1С ассемблером тест проводили?
Siemargl
18.04.2017 21:17-1Зачем?
C# может играть в той же нише веб-сервисов, что и PHP — они конкуренты, а асм тут не конкурент.
Конечно, правильнее было еще сравнить потребляемую память: PHP — 7Mb, C# — 7.8Mb
На этом тесте паритет, надо смотреть реальные задачи. Но в целом — для бомжатников — где 1000 сайтов на одном сервере, PHP будет в выигрыше.
altai2013
19.04.2017 07:04+282,7% рынка у PHP, 15,1% у ASP.NET
Какие уж тут конкуренты :)
Платформа MS полумёртвая и доля её продолжает снижаться каждый месяц. За последний год она упала на 0,6%.
poxvuibr
19.04.2017 07:23+6Выразительность языка сравнима. На ассемблере программу писать существенно дольше. На C# и на PHP — примерно одинаковое количество времени получится.
youlose
19.04.2017 11:28+11. тест Мандельброта не имеет ничего общего с сайтописанием
2. вы в реальной жизни, на болиде «формула 1» ездите, надеюсь? (а то иначе дуализм какой-то получается)
AlexLeonov
18.04.2017 17:11Хорошая статья, спасибо, но вот это вот:
5.0.5
— зачем?
5.1.6
5.2.17
5.3.29
5.4.45
5.5.38
Really, нет никаких причин тестировать и использовать старые версии. Переход на PHP 7.1 практически бесплатный для любого проекта.rockin
18.04.2017 18:09+4Всё очень просто — не все продукты дожили до времён семёрки, а в семёрке не всё поддерживается.
У меня лично одна виртуалка на пятёрке как раз для поддержки старья, но и пятерки мало оказалось совсем недавно — принесли на флешечке лицензионный продукт (бекап сайта) десятилетней давности, мол, разверните и запустите. В случае малоизвестной CMS, для которой нельзя просто взять и скачать обновления ловить ошибки по сотне-другой файлов удовольствия мало.
Перейти на 7.1, конечно, можно с любого продукта, но иногда запустить бекап надо ещё вчера.
Так что, причин тестировать, может, и нет. Зато причины использовать есть.
NickKolok
18.04.2017 20:33+2Joomla 1.7.2
Поддержка брошена. Но сайт был работающим, пока админы не решили обновить РНР с 5.5 до 7.
Пришлось объяснять начальству, почему оно поломалось…
А апдейт джумлы на 3.5 штатными средствами не предусмотрен. Даже через промежуточные версии.T-362
19.04.2017 13:20Опущу комментарии и эмоции, возникшие из-за воспоминаний о работе с этой ЦМС, и спрошу только одно — а почему вообще джумлу использовали?
Navij
19.04.2017 15:00+1Ни в коем случае не хочу сказать, что Джумла — хорошая CMS, но, отбросив программистский снобизм, хочу сказать, что, если сайт работает и выполняет свою функцию, то небольшой компании, далёкой от IT, могло быть просто бессмысленно тратить деньги на разработку сайта на нормальной платформе.
NickKolok
20.04.2017 02:00Именно. Сайт — он не для того, чтобы удовлетворять потребности программиста, ответственного за него, в изучении новых технологий.
NickKolok
20.04.2017 01:59Сайт достался от предшественника. Так как сайт был в первую очередь нужен дл того, чтобы он работал, переход на новую ЦМС был просто бессмысленен. Работает — не трожь.
T-362
20.04.2017 12:38+1Сайт — он не для того, чтобы удовлетворять потребности программиста, ответственного за него, в изучении новых технологий.
Сайт достался от предшественника.
Joomla 1.7.2
Ощущение что изначальная идея использования джумлы как-раз «удовлетворяла потребности программиста, ответственного за него, в изучении новых технологий» вместо «нечто максимально живучее для варианта „работает — не трожь“ ».
Ну да ладно, в любом случае глубоко соболезную горю тащить это необновляемое легаси.
Fortop
19.04.2017 01:20-2Не бесплатный.
Причем совсем не бесплатный.
Особенно в части проектов завязанных на старые кодовые базы и расширения к пхп.
Например, php-gearman отлично сегфолтится под 7-ку, тогда как под 5.5 работал.
rPman
18.04.2017 19:34Я понимаю, тесты производительности в основном для числодробилок, как их можно интерпритировать?
Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?
p.s. когда я слышу о производтельности php я сразу напоминаю, что очень многие программисты активно используют массивы со строковым ключом как идентификатор поля в своей универсальной структуре (вместо числового ключа, с определенным заранее дефайном, и это я молчу про поддержку классов или, например, использование кортежей), скорость выборки элементов в таком массиве уже не будет зависеть от версии php так сильно?sumanai
18.04.2017 20:15скорость выборки элементов в таком массиве уже не будет зависеть от версии php так сильно?
Вы не поверите, но массивы были сильно оптимизировали в PHP 7, так что да, даже такая казалось бы простая вещь, как массив, может быть улучшена.rPman
18.04.2017 23:48+2охх, ну нифига себе, двухкратный прирост:$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;
rPman
20.04.2017 17:44хех, реализация для nodejs, как неоднозначно: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);
Maiami
21.04.2017 06:16+3а теперь внимание, шок (у меня лежала старая версия от 2015 года)
Этот, немного странноватый, тест наверное единственный случай когда старая нода оказалась быстрее, так как в реальном коде все наоборот.
Причешем немного код на php, и добавим 2 missed счетчика, чтобы была интрига у кого рандомайзер лучше:
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; $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 . '; ';
Mendel
21.04.2017 13:09-2если бы были просто массивы (не ассоциативные)
Не, ну это не совсем честно. Вы ведь код под ноду оптимизировали?
Тогда уж используйте SPL а не классические массивы. А там преимущество будет уже не столь заметно.Maiami
21.04.2017 13:21+1Не, ну это не совсем честно. Вы ведь код под ноду оптимизировали?
Что не честно? Вы процитировали цитату из части про «если бы», о чем речь?
Я вообще ничего не оптимизировала, я написала как будет правильно под ноду.Mendel
21.04.2017 18:49Вы переписали код ноды так, как более правильно писать под ноду. Было? Было.
Использовались более эффективные конструкции языка.
Далее было сказано, что " если бы были просто массивы (не ассоциативные), то node был бы еще быстрее чем php". Было такое утверждение? Было.
Данное утверждение логически верно. Я не могу сказать что вы ошибаетесь, или врете.
Всё так. Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.
Они тоже не очень удачно спроектированы, и я думаю что даже с ними нода будет в выигрыше. Но тем не менее если уж сравнивать код на разных языках, то стоит использовать оптимальные конструкции для каждого языка, даже если они несколько отличаются.
А значит _честно_ будет использовать не числовые массивы, а именно классы из SPL.
Двусвязный список или ФиксМассив, не суть.
Мне вот интересно, это я действительно настолько непонятно выразился что нужно было оценивать человека, а не комментарий, причем массово, или это оппоненты настолько плохо знают язык (в статье про пхп прошу заметить, не про ноду), что не пользуются SPL и не поняли моего высказывания?sumanai
21.04.2017 20:42+2По этой причине были созданы другие структуры данных, а именно специальные классы.
Кажется, эти специальные структуры проигрывают общим в php 7.0.
Maiami
22.04.2017 06:11+2Всем известно что у пхп массивы довольно медленная часть, поскольку они универсальные. По этой причине были созданы другие структуры данных, а именно специальные классы.
Любой кто когда либо работал с 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.youlose
22.04.2017 11:01По идее там и Map не нужен в JS поддержка же множеств есть
Врем заполнения на 20% уменьшитсяMaiami
22.04.2017 13:12Просто Set специфичен (не прочитать рандомное значение, без перебора всего), а Map это почти прозрачная замена ассоциативного массива с удобным доступом
youlose
22.04.2017 13:37Set не перебирает все значения, сами подумайте, чтобы отличать одни уникальные значения от других нужен какой-то признак уникальности и работа с ним по сути похожа на работу с хэшмеп. С Set обе стадии скрипта быстрее чем с Map:
$ node map.js
filling: 637.137ms
counting: 7916.720ms
10388534; 5187885;
$ node set.js
filling: 502.317ms
counting: 7290.966ms
10384428; 5192356;
И в данной задаче сначала заполняются случайные ключи хэшмепа и им присваивается значение true (которое не используется, потому что оно не нужно). А потом проверяется наличие ключей в этом хэшмепе.
То есть обе операции которые используются во множествах.Maiami
22.04.2017 13:42Это да, я имела введу, что Set подходит под специфические задачи, а Map под любые
bat
19.04.2017 06:55Например реализация websocket сервера на php, будет ли она быстрее на php7/8/5? на те же 40%?
шо, опять? ©rPman
19.04.2017 20:13Шутки не понял, если у меня сервер на php то мне будет сложно правильно использовать сторонние (но не невозможно само собой), а значит реализация именно серверной части с обслуживанием подключений и пользователей будет на php, гугл выдает с десяток реализаций.
Мало того, неплохой нормой становится http сервер тоже на php (само собой прикрытые nginx proxy), это очень часто заметно поднимает производительность итогового результата (за счет возможности повторно не инициализировать переменные на каждый запрос).
Логичный вопрос — смена версии даст сильный прирост или нет?youlose
19.04.2017 22:03Это лучше попробовать, на сайтах на symfony 2 у меня был прирост в 2 раза по процу и снизилось потребление памяти на 30% после перехода с 5.6 на 7.0
bat
20.04.2017 11:36Логичный вопрос — смена версии даст сильный прирост или нет?
для вебсокетного сервиса на PHP по скорости вряд ли, по памяти точно
Шутки не понял, если у меня сервер на php то мне будет сложно правильно использовать сторонние (но не невозможно само собой), а значит реализация именно серверной части с обслуживанием подключений и пользователей будет на php, гугл выдает с десяток реализаций.
да не было никакой шутки
да можно, решения есть, но при поддержке такого решения постоянно придется решать проблемы, которые давно уже решены.
php-шнику на том же nodejs ws-сервис сделать не сложнее чем на php, если не проще. и экосистема там богаче в этом плане, это его ниша.rPman
20.04.2017 16:43Маленький оффтоп про экосистему.
Буквально недавно решал задачу, как в пределах одного процесса заставить эффективно по ресурсам работать websocket (а потом и push http) сервер и асинхронную загрузку файлов по http (позже и подключение к сторонним websocket).
на nodejs у меня не возникнет никаких проблем в реализации этого?
Используя готовые решения — websocket сервер на socket (расширение php) и асинхронную загрузку curl_multi_… красивого решения не получается — у них разные механизмы организации цикла
p.s.у каждого свой метод ожидания события на сокете, нет метода, который позволил бы ждать события в обоих библиотеках, можно только проверить их наличие по отдельности, т.е. либо 100% нагрузка в пустом цикле либо вставка слипов и таймаутов, которые заметно замедлят работу при нагрузкеbat
21.04.2017 06:53подобные вещи я и имел в виду
предположу, чтобы подобное реализовать, потребуется реализация HTTP на PHP и работа с удаленным сервером через сокет. дальше, наверное, потребуется асинхронная работа с диском, БД…
на nodejs с этим проблем не будет
можно использовать Go, но это тема для холивара )rPman
21.04.2017 19:46я смотрю примеры библиотек использования websocket на nodejs, у них нет явного вызова цикла обработки событий, т.е. этой обработкой занимается сам node, я считаю это огромный бонус, жаль этого нет (а так же соглашений по событийному циклу) в php.
XNoNAME
18.04.2017 22:57-3Не хватает в таблице строки с каким нибудь другим языком (java например или go), что бы иметь общее представление о производительности php7.
Nakosika
19.04.2017 01:17-6На что только люди не пойдут чтобы не учить нормальный язык программирования...
0xd34df00d
19.04.2017 02:55+12Не говорите, сам удивлён малым количеством хаскеля в продакшене.
serg_deep
19.04.2017 12:00+1Вы наверное имели ввиду С, JS ну или Хаскель, ну а может Фортран, конкретизируйте пожалуйста. Не нужно стесняться в своих предпочтениях в языках, нам всем ведь так интересно "Ваше" мнение о "Вашем" "нормальном" языке программирования.
P.S. Самое забавное в этом всём, что я ни разу не видел, чтобы где-то в посте про JS или там Хаскель, ну или %подставить любой другой язык программирования%, кто-нибудь из адептов PHP втыкал свои 5 копеек про "нормальный язык". У "Вас" (всех хейтеров php) что какая-то php-фобия? Может быть он у "Вас" в детстве конфетку во дворе отобрал или упаси господи в возрасте 5 лет зажал "Вас" в подъезде 1 на 1 и пытался принудить "Вас" попользоваться им? Что с "Вами" не так?
Nakosika
19.04.2017 12:03Мог бы ответить вам по существу, но не на такой хамский выпад, конечно.
serg_deep
19.04.2017 12:41-1Правильно делаете, мне абсолютно не интересно читать про "Ваши" детские душевные травмы.
Navij
19.04.2017 15:17+2А я бы с удовольствием почитал ваши доводы. Ну то есть тема, конечно, обсосанная до невозможности, но холивар на то и холивар. Имхо PHP для своей задачи подходит отлично, оттого и такой высокий процент на рынке. Он простой, всепрощающий, быстр в разработке, и позволяет быстро и легко решать каждодневные задачи, коих 99% в вебе. Писать на нём работающий код может даже не очень квалифицированный программист, но, повторюсь, для 99% задач в вебе и не нужна высокая квалификация. Разработка на более «правильных» языках была бы гораздо дороже и сложнее в поддержке. Хотя это и спорный вопрос, если бы исторически, например, Питон занимал такой процент рынка, то и программистов на нём было бы больше. Но на данный момент картина мира такова, и мне лично не видится, что из-за этого мир катится в пропасть, наоборот — сеть растёт и развивается, становится лучше. К тому же к JS, например, у меня лично гораздо больше претензий, и то — при сегодняшнем развитии фреймворков он стал гораздо более терпим.
Nakosika
26.04.2017 22:59+1Да я не болею за какой-то конкретный язык программирования, просто есть «более лучшие». PHP в принципе язык без достоинств, если не считать легкость обучения. Есть языки быстрее из коробки, есть типобезопасные, есть портируемые, есть сверхнадежные, и т.п. Потому я и написал «чтобы не учить нормальный язык», в данном случае нормальный — это будет что-то более подходящее под требование, что-то более быстрое.
Просто товарищи за меня додумали что я якобы критикую PHP. Я полностью с вами согласен — в рейтинге «самый простой язык для бэкенда» PHP будет в топе, и очень часто этого достаточно. Простота и отсутствие необходимости обучаться — это вещи в данном случае взаимосвязанные, на что я и указал.
poxvuibr
27.04.2017 11:03+1А я бы с удовольствием почитал ваши доводы. Ну то есть тема, конечно, обсосанная до невозможности, но холивар на то и холивар.
Перед каждой переменной нужно ставить знак доллара. Программисты правда к этому уже настолько привыкли, что даже не замечают насколько это странно .
- Доступ до полей класса производится через ->, а не через точку. Программисты правда к этому уже настолько привыкли, что даже не замечают насколько это странно — печатать два символа вместо одного.
В рамках холивора, вот два объективных недостатка, которых легко могло бы и не быть.
serg_deep
27.04.2017 12:16-1Ну хватит уже, ну правда. На эти вопросы уже раз 500 давали ответы и на хабре и везде где только можно.
Это все недостатки которые вас беспокоят или есть еще что-то?
poxvuibr
27.04.2017 12:44+2Ну хватит уже, ну правда. На эти вопросы уже раз 500 давали ответы и на хабре и везде где только можно.
Ну да, ответы обычно именно такие — в стиле — я пишу на PHP и эти недостатки меня совершенно не беспокоят. Это не значит, что недостатков нет.
Это все недостатки которые вас беспокоят или есть еще что-то?
Есть, конечно. У всех языков программирования есть недостатки. Эти конкретные — просто хороший пример. Очевидно они есть. Очевидно это недостатки. Отсутствие конкарренси можно оправдать например тем, что php не решает задач в которых она нужна. А тут — просто недостаки, без оправданий.
serg_deep
27.04.2017 13:16-2А как по вашему Perl, С и Lua плоие языки? Можно вас попросить расставить четыре языка Perl, С, Lua и Php. В начале пусть будет самый хороший, а в конце будет самый плохой. Ну и конечно ответьте полностью какие еще недостатки вам не нравятся. Потому что вы весьма хитро и уклончиво ушли от ответа.
poxvuibr
27.04.2017 15:43+1Я не уходил от ответа. Меня спросили есть ли ещё недостатки php, которые меня беспокоят, я ответил, что есть, но сказать хотел именно о тех недостатках, о которых сказал.
Что касается языков — Lua и Perl я не владею. С — успешный язык, недостатков в нём много, они расписаны много где. Но я про конкретику из PHP вообще.
serg_deep
27.04.2017 16:03-1И снова как и в предыдуший раз "PHP плохой потому что плохой. А почему? Да не знаю я, просто плохой. Ну точика мне не нравится и через черточку со стрелочкой работать мне не нравится, а в остальном я не могу больше ни чего сказать". Что с "вами" всеми не так? Вы если холиварите и ввязываетесь в дискуссию, отвечайте хотя бы за свои слова, подробно конкретно с аргументаций, а то ответы на уровне 10 класса. Фраза "ну просто плохой", это не формат ИТ ресурса. Я умываю руки...
Вас "всех" явно php в подъезде зажал.
poxvuibr
27.04.2017 16:10+2И снова как и в предыдуший раз "PHP плохой потому что плохой.
На случай, если вы невнимательно читали в прошлый раз, я дам выжимку из того, что я говорил. У php как минимум 2 недостатка.
- Нужно писать доллар перед переменными, хотя без этого можно было бы легко обойтись.
- Для доступа к полям класса нужно использовать -> а не точку. 2 символа вместо одного.
Вы почему-то в этом тексте видите буквы, которые складываются в "php плохой". Ну, бывает.
serg_deep
27.04.2017 16:47-2Да бесполезно с вами разаговаривать, вы не владеете информацией более чем полностью.
- Это пришло если что из Perl. Потому что php писался под впечатлением от perl, а там то же переменные начинаются с $. Вы да же не осилили мой предыдущий комментарий который был с подвохом. А все потому что в теме не разбираетесь и слышали отдельные слухи. Php плохой, С хороший, но со своими недостатками. А спроси вас больше, вы не ответити ни слова.
- Это отдельная операция, называется конкатенация строк. В начале, в самой первой версии php, ООП там вообще не было. По-этому доступ к членам класа там не то что не был продуман, о нём вообще не думали, зато конкатенировать строки нужно было постоянно, по-этому выбрали короткую и простую запись. А когда появились объекты, чтобы не ломать обратную совместимость стали использовать '->'. И вообще-то она очень удобная, не нужно городить фиктивные пустые строки как в js. И опять же, в предыдущем комменте я не просто так спросил про Lua. Представляете, в Lua конкатенация строк осуществялется (барабанная дробь) аж целыми двумя точкам '..'. Наверно теперь Lua для вас ну просто "ублюдок" какой-то?
poxvuibr
27.04.2017 17:34+2Да бесполезно с вами разаговаривать, вы не владеете информацией более чем полностью.
Действительно, ведь в php давно уже не надо ставить $ перед переменными и доступ для полей не через ->, да? :)
Php плохой,
Я так и сказал? Тогда цитируйте, не стесняйтесь.
- Это пришло если что из Perl. Потому что php писался под впечатлением от perl, а там то же переменные начинаются с $.
- Это отдельная операция, называется конкатенация строк. В начале, в самой первой версии php, ООП там вообще не было. По-этому доступ к членам класа там не то что не был продуман, о нём вообще не думали
Ну да, объективные недостатки php продиктованы тяжёлым наследием прошлого. От этого они не перестают быть недостатками.
И опять же, в предыдущем комменте я не просто так спросил про Lua. Представляете, в Lua конкатенация строк осуществялется (барабанная дробь) аж целыми двумя точкам '..'. Наверно теперь Lua для вас ну просто "ублюдок" какой-то?
Да нет, как конкатенировать строки не очень важно. Важно как прописываются операции, которые приходится делать постоянно. Как делается в Lua доступ к полям?
- Это пришло если что из Perl. Потому что php писался под впечатлением от perl, а там то же переменные начинаются с $.
rPman
27.04.2017 15:18На си и си++ тоже есть '->' и '.', собственно первое — переход к полю объекта по ссылке, второе, к самому объекту. Это вполне в духе php — объекты там все по ссылке.
Использование $ перед переменной не большая цена, к тому же это фича, двойной знак — переход к переменной по имени в переменной. Мало того, символ $ сразу говорит что мы имеем дело с идентификатором-переменной, без необходимости взгляду анализировать окружение (когда ищешь беглым взглядом что-либо, переменные сразу бросаются в глаза).
И вообще, короткая запись не всегда благо, лучше лишних символов добавить если читаемость повысится.poxvuibr
27.04.2017 15:47+1На си и си++ тоже есть '->' и '.', собственно первое — переход к полю объекта по ссылке, второе, к самому объекту. Это вполне в духе php — объекты там все по ссылке.
В си и си++ есть -> потому что точка занята другим похожим действием. В php точка посажена на конкатенацию, которая происходит существенно реже, чем обращение к полю объекта.
Использование $ перед переменной не большая цена
Я и говорю, программисты уже не замечают, насколько это странно.
Мало того, символ $ сразу говорит что мы имеем дело с идентификатором-переменной, без необходимости взгляду анализировать окружение
Странно, что эту крайне важную фичу не засунули в языки, которые появились позже php :). Вы не пользуетесь подсветкой кода?
И вообще, короткая запись не всегда благо, лучше лишних символов добавить если читаемость повысится.
Не всегда. Но это не тот случай.
Mendel
28.04.2017 15:19+1В целом мне не особо по нраву слабая динамическая типизация.
Но это одна из тех вещей которые привели пхп к его нынешней популярности.
И поскольку слабая динамическая типиизация это объективная реальность, то скажите мне, на что вы предлагаете заменить конкатенацию? Если точка будет занята, то что же у нас будет?
Привычный плюс? Тогда что мы получим на выходе если у нас будет $x = '2' + '2';?
Я пришел в пхп во времена пхп4. И меня тоже бесили эти странности языка (доллар не бесил).
Тогда еще по факту не было ООП в пхп (оно и сейчас еще не очень распространено, если по честному). Но все равно раздражало.
Однако положа руку на сердце — плюс тут будет еще страшнее.
И да, если в пхп4 (четыре Карл!) доступ к членам класса был еще не очень популярным, то что мы хотим от первых версий.
Странно, да.
Непривычно, да.
Но логично.
И к недостаткам языка оно явно не относится.
Недостаток языка это хаос в функциях.
Недостаток языка это то что все еще нормальная типизация скаляров не доступна на многих хостингах (пхп7+ еще недостаточно популярен). Недостатков много. Но в целом они следствие его достоинств, и воспринимаются как данность.
Что до _непривычности_, а это именно непривычность — ну бывает, чё.
Никогда не пробовали писать под 1С?
У меня ушло недели две, чтобы перестать обращать на это внимание.
Ну перевод и перевод.
И у языка 1с есть куча недостатков. Например его предметнориентированность подразумевает неестественные механизмы расширения существующих сущностей. ООП был бы удобнее.
Но русский язык это просто решение. И решение умное, правильное и удачное. Это его сильная сторона да.
Почему русский?
Многие заблуждаются думая что «глупые недопрограммисты ленятся заучивать конструкции». Это не так. Ведь конструкций не много. А правда в том, что предметная область вся на русском. План счетов как называть? Ну ок, это расхожий термин, вызубрим перевод. А что такое Invoice в коде Васи? Что он имел ввиду? У нас ведь не ВЭД. Это счет или накладная?
Или может вообще ТТН? (Я знаю что у большинства терминов есть перевод, но много ли заказчиков их знают? И знаю правильно? Программист должен знать про предметную область больше чем заказчик? Знать все эти явления, суть их, названия, да еще и переводы? Зачем?
Писать if актВыполненныхРабот.проведен then… можно. Но… зачем? Чтобы было привычнее? Все равно не привычно). А их SQL забавен, да. Взял сейчас томик справочника, нашел пример какого-то запроса, и смог понять только после мысленного перевода всех этих «объединить» на join и т.п. А когда имел с этим дело — на работе по русски, дома по английски, и нормально читалось и писалось.
Многабукафф, да.
Еще раз что сказать хотел. Коротко. $x = '2' + '2'; должно давать 4. Так проектировался язык.
И для него это норма. Такие были задачи. В форме данные все нетипизированные, в строках приходят, потом разбираем. Так что в нише пхп слабая динамическая была очень даже.
Сейчас при готовой инфраструктуре оно может и не очень надо. Но инфраструктуры бы не было, если бы не простота…
ПС: я вкурсе что вы не говорили что «пхп говно», я чисто в качестве аргумента что именно ваши недостатки — недостатками не считаю.
dukei
19.04.2017 10:09+1А много ли выигрыша от JIT, учитывая, что пхп умирает после каждого запроса в подавляющем большинстве сценариев использования? Или там скомпилированный код будет в opcache сохраняться?
Mendel
19.04.2017 10:22Числодробление хорошо, но не хватает оценки памяти.
Плюс в реальности довольно много нагрузки приходится на всякие обходы массивов или объектов.
Бутылочным горлышком обычно являются таки СУБД а не пхп. Скорость не везде, но часто вторична, а вот прожорливость по памяти бывает мешает.artmel
24.04.2017 08:45А у меня сейчас например главное это числодробилка. Памятью и СУБД можно пренебречь. А вот в предыдущем проекте, пришлось перевести все, что только можно но nosql хранилища. Иначе был ад.
Вся беда в том что проекту более 10 лет и перевод на php7 тяжек.youlose
24.04.2017 09:09Если у вас числодробилка (настолько что это важно), то нужен не php, а любой язык со статической типизацией + определить интерфейс взаимодействия пхп (если уже есть легаси с ним) и этим новым языком.
artmel
24.04.2017 09:22Нужно конечно. только там работы на год минимум. А потом еще баги вылавливать.
С точки зрения программиста нужно все сжечь и переписать.
А с точки зрения руководителя проекта, просто перейти на новую версию php по возможности и более мощный сервер оплатить. А новые модули, писать на C++ но возможности. А часть вообще планируется под GPU.youlose
24.04.2017 10:57Не я не про переписать конечно же, потому что числодробилка — обычно это какая-то небольшая часть от проекта, а как раз про что в сервис вынести числодробильную часть и её уже писать на подходящем диалекте,
Razaz
24.04.2017 12:41Уже выше упоминал Peachpie — PHP поверх CLR. Тоесть код вроде как будет скомпилен в IL и можно пользоваться всеми приемуществами CLR… Вот бы кто попробовал и рассказал как оно…
nefone
19.04.2017 18:13Результат на лицо. Радует что растет производительность любимого языка программирования.
http3
Вырвиглазная таблица.
http3
Уже пофиксили…