8,5
рейтинг
1 декабря 2015 в 19:43

Разработка → PHP 7.0.0

PHP*
Несколько часов назад Anatol Belski, релиз менеджер PHP, тегнул стабильный релиз PHP 7.0.0. Это значит, что сегодня-завтра мы увидим официальный анонс на php.net. Наконец, можно будет пользоваться новыми прекрасными возможностями: строгой типизацией, оператором ??, анонимными классами, безопасным рандомом и многим другим. Как приличный бонус все перешедшие получат значительный прирост производительности.

В официальной англоязычной документации уже доступен раздел с описанием всех новых возможностей и инструкциями по миграции старых проектов: https://secure.php.net/manual/en/migration70.php. Также почитать о семёрке можно и на хабре:



Апдейт: а вот и официальный анонс.
Планируете ли вы перевести свои проекты на PHP 7?

Проголосовало 2325 человек. Воздержалось 553 человека.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Александр Макаров @SamDark
карма
281,4
рейтинг 8,5
PHP, Yii, Android
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (103)

  • –18
    Некоторые проекты работают еще на 4-ке. Большинство на 5-ке, при чем не важно какой. Особого смысла в переходе не было.
    7-ка первая версия пхп (после 4-ки) на которую появляется смысл переходить, хотя по уму конечно 7.1 подождать…
    • 0
      7.0.1?
      • +3
        Проектов много:) Начнем переход на 7.0.0 уже, но самые большие, критичные и важные подождут именно 7.1.0.
        • +11
          Тогда уж было было логичино ждать 7.1.1.
    • +3
      Вкусовщина. 5 и некоторые другие релизы после вполне заслуживают, чтобы на них переходить.
      • 0
        Безусловно от перехода к 4=>5 и 5.x=>5.y плюсы появляются, но лично у нас они просто не перевешивают принцип «работает = не трогай». А вот 7-ка это первая версия (после 4-ки, на которую мы перелезали с 3-шки), в которой этим принципом можно в изрядной степени поступиться.
        • +5
          Почему? ООП в пятёрке был не нужен а строгая типизация нужна?
          • +1
            Производительность нужна.
            7-ка вроде как очень неплоха, при чем не только по результатам тестам, но и по декларируемым принципам улучшения оной. Что очень и очень радует.
            ООП в 5-ке вещь полезная, но переводить из-за этого стабильные работающие проекты с 4-ки на 5-ку реализуя принцип «ооп ради ооп» смысла не видели. Тот же drupal достаточно долго жил без использования механизмом ООП php и никто не жужжал:)
            • +1
              Ну, зачем-то и Drupal перевели. Видно, что не ради ООП как такового.
            • +8
              То есть безнадежно устаревшее 100% дырявое ПО вас не смущает совершенно? Не хотел бы я оказаться на вашем сайте…
              • +6
                То есть безнадежно устаревшее 100% дырявое ПО вас не смущает совершенно?
                У Вас тут два утверждения, ответим отдельно
                1) Термин «устаревшее» он гуманитарный, а не технический. Аргументация вида «ой, это устаревшее, это не модное, ой всё» не убедительна ни разу. Так что это мы принять не можем…
                2) Термин «дырявое» он уже технический. И тут Вы отчасти правы. Но 4-ку мы на проектах доступных снаружи не используем (парсеры, грабберы, обработка данных, спайдеры, аналитика), а за секьюрити фиксами 5-ки следим.
                • +1
                  1) под устаревшим я имею ввиду не моду, а то, что к примеру, разработчики не поддерживают его (аналогично устарел IE7, и пока не устарел IE11, но ему до нового года осталось)
                  2) интранет это, конечно, не так плохо, но всё же и не оправдание использовать гарантировано дырявое ПО, тем более, если оно является платформой

                  Тут нет варианта отчасти, можно легко нагуглить какой-то оносительно простой эксплойт и успешно нанести урон бизнесу. Не знаю как вы, но для меня это на разу не оправдание. Там же и ОС, получается, соответствующая, с того времени, и веб-сервер, и прочее? Грустно это:(
                  • +2
                    Это не самый лучший пример в мире, но недавно вдруг обнаружилось (во время сбоя), что аэропорт во франции использует винду 3.11. Не поддерживаемую и очевидно дырявую.

                    Тут нет варианта отчасти, можно легко нагуглить какой-то оносительно простой эксплойт и успешно нанести урон бизнесу. Не знаю как вы, но для меня это на разу не оправдание. Там же и ОС, получается, соответствующая, с того времени, и веб-сервер, и прочее? Грустно это:(
                    Вы сами придумали какой-то странный сценарий и сами же его разгромили.
                    Вебсервер, ось — свежие. Мускул — свежий. На сервере входящие коннекты вообще запрещены, кроме как по ssh по ключам.
                • +1
                  А разве при переходе на 5.2 или 5.3 у вас что-то сломается? 5-ка по-моему с 4-кой отличной совместимостью обладает.
            • +2
              Производительность нужна.

              PHP5.4 работает насколько я помню пошустрее PHP4 (в зависимости от задачи и реализации), при гораздно больших возможностях писать поддерживаемый код.
          • +5
            Всё-таки не стоит называть скалярные тайпхинты строгой типизацией.
        • +1
          Просто не нужно затягивать переходы, 7 не должна сильно ломать код написанный на том же 5.5 или 5.6, а адаптация ради более высокой производительности стоит своего времени.
          • +7
            Особенно в этот раз. Производительность не просто немного подняли…
          • НЛО прилетело и опубликовало эту надпись здесь
        • +1
          Судя по вашим коментариям, вы не стоите тех денег которые указаны у вас в профиле.
          • +22
            Так нам же не за комментарии платят:)
    • 0
      учитывая предыдущие циклы, придется год его ждать как минимум…
      • +3
        В предыдущих циклах покрытие тестами было значительно хуже. Сегфолты к релизу по большей части пофиксили. Остальные уйдут в 7.0.1.
    • +13
      Какими же печеньками вам приходится держать разработчиков под php4? Если бы мне на собеседовании сказали мы используем php4, я бы поблагодарил за встречу и удалил телефон рекрутера
  • +4
    Прекрасная новость. Давно жду стабильного релиза.
  • +3
    А кто-нибудь знает где почитать по поводу PECL-расширений? Как там у них с семеркой. Лично для меня это основной вопрос — без некоторых из них не представляю вообще жизнь проекта.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    Xdebug 2.4.0rc1
    Вышел под 7.0, все отлично, значит можно применять в dev.
  • 0
    Анонимный класс можно наследовать от анонимного класса?
    • 0
      Надо попробовать :)
    • 0
      А как вы это себе представляете?)

      Кстати что забавно — года два назад на девконфе во время докалда по php-ng я поинтересовался не собираются ли запилить анонимные классы — тогда мне ответили что нет смысла делать из php вторую java =)
      • 0
        нет смысла делать из php вторую java


        ну сам zend инвестировать в эту фичу не хотел, появилось RFC + PR. Опенсурс же.
      • 0
        Может быть присваивать описание класса в переменную и ими манипулировать? =) Сейчас это скорее одноразовые классы нежели анонимные. Для функций ведь сделали closures. Надо для классов что-то подобное.
        • +1
          Может быть присваивать описание класса в переменную и ими манипулировать?

          Ну как бы, тип вы новый не объявляете таким образом (анонимность же), а стало быть вы не сможете этот класс реюзать. По сути вы можете представить что анонимные классы это final классы.

          Для функций ведь сделали closures

          И это очень хороший пример различия между именованными классами и безымянными. Безымянные должны быть использованы только единыжды, это class expressions (как анонимные функции являются function expressions). То есть анонимные функции вы так же должны использовать только единыжды (а не имитировать ими именованные функции).

          Наследование никак не в писывается в концепцию «одноразовости».
  • 0
    Одно огорчает — всякие хостинги долго обновляются.
    • 0
      хостингам просто не выгодно, много проектов будет на < 7 версии, а это значит пока 70-80% клиентов не запросят 7 хостинг и не сдвинется с места.
      • +2
        Выгода для хостингов есть в уменьшении нагрузки на сервере при переходе на PHP 7. Но, конечно, хостер никогда не может заранее знать, не отвалится ли у какого-нибудь клиента старый проект, поэтому просто так взять и перевести всех на PHP 7 не получится. Многие хостеры уже давно предлагали в панели переключатель версий PHP, надеюсь и PHP 7 туда подтянут, благо этот релиз хорошо распиарен, запрос в массах есть, даже среди wp разработчиков.
      • 0
        Пока они будут ждать выгоды от потенциальной мелочи, может убежать много крупных из этих 70-80 %.
    • +2
      большинство хостингов дороже какого-нибудь дешевого облачного инстанса — там можно что угодно делать
      • 0
        Только это часто трудно объяснить абстрактному заказчику, а некоторые — так и вовсе на бесплатных хостингах сидят: «какие такие впс? не, не слышали...»
        • +2
          Им и не надо слышать. Им надо готовый продукт, а не проблемы по его установке (даже на обычном хостинге).
          Сами производите установку и настройку своего ПО.
          • 0
            Ну я об этом же и говорю — приходит среднего ума заказчик, без особого техзадания требует средненький сайт (а для среднего ума фрилансеров типа меня — это хрестоматийный кейс). В итоге, ты ему сдаёшь проект в виде архива (далеко не все дают данные к хосту), а потом начинаются пляски с бубнами. У меня совсем недавно было три случая подряд, когда у заказчика на хостинге версия php была 5.3, а много кода уже наработано и используется под 5.4+ (как минимум, сокращённые записи массивов, трейты, нотация фигурных скобок) — в итоге, приходилось в авральном порядке вставлять легаси-костыли; и ведь с точки зрения заказчика ему «не надо слышать» про какое-то там php, но с моей — это именно вина неповоротливости хостеров, от которой страдают все: и разработчики, и заказчики (небезопасно, медленно), и сами хостеры (всех последующих клиентов буду отговаривать от использования подобного хостинга).
            • 0
              На мой взгляд в описанной ситуации виноваты вы как исполнитель:
              а) Не смогли объяснить заказчику зачем вам нужен доступ. Простой аргумент: из кода пхп который он потом зальёт на этот хостинг можно будет натворить дел похлеще чем с простым доступом по фтп/сфтп…
              б) Даже если всё таки не даёт доступ — выяснить в какой среде будет работать ваш код и (желательно) это утвердить в ТЗ, если оно конечно есть. Если не знает или не хочет узнавать что там и как — попросить загрузить файл с phpinfo() и прочим.
              в) Работать без ТЗ — вообще не комильфо. Это геморой как для вас так и для заказчика (очень редко случается когда всё проходит гладко).
              г) (опционально) Рассказать о преимуществах таких простых вещей как «дроплет на DO за 5 баксов/месяц» и «ssl/https ещё за 5 баксов/год». Может быть вам лично на это всё пофиг, но вашей карме от этого точно хуже не станет :)
              • 0
                Тут все пункты с а) по г) разбиваются о суровую действительность нынешнего мелкого сайтостроительного бизнеса, ибо чаще всего это выглядит так:
                1. Человек, например, М., мой знакомый — звонит и говорит: «нужен сайт, бюджет 5 рублей, сроки позавчера, техзадания и прочих требований нет и не будет, нарисуй „что-нибудь“;
                2. Быстренько рисуется „что-нибудь“, ну в общем,
                классика:


                3. Оно также быстро одобряется, файлы отдаются человеку М., дальше он их отдаёт заказчику З.
                4. Связи между исполнителем И. и З. нет и не будет никакой.
                5. Очень изредка, в случае проблем вроде описанной, иногда даются данные к хосту или хостингу, тогда они оперативно исправляются.

                Конечно можно говорить, что в данном случае я виноват, раз работаю с таким Г-ом, но уж простите, на фоне зарплаты в $ 200 и при этом вполне московских цен, выбирать особо не приходится — любой сторонней работе надо радоваться. Другой толковой работы для айтишников тут вообще нет — есть пара конторок, где ты будешь сидеть в офисе за те же $ 200 и клепать всё то же „что-нибудь“, только уже из-под палки и на дядю.
                • 0
                  Не понимаю как так у вас связан «фриланс» и некое «тут». Для меня фриланс это в первую очередь интернет. Если уж мы тут с вами переписываемся, значит интернет у вас есть :). Следовательно можно сделать вывод что у вас есть доступ до фриланс-бирж типа местного http://freelansim.ru/… Так зачем тогда «нужен сайт, бюджет 5 рублей» если можно нормально работать? Я что-то упускаю?
                  • –1
                    Фриланс у каждого свой, сударь.
                    • +1
                      Ну то есть тогда не «выбирать особо не приходится», а как-то вроде «я придумал себе свой фриланс, а потому —
                      в данном случае я виноват, раз работаю с таким Г-ом
                      • +1
                        Ну я рад, если Вам квалификация, опыт, время, портфолио, место физического расположения, финансовой обеспеченности и чувство собственной важности позволяют эффективно работать на фриланс-биржах, и каждый раз выбирать хорошие проекты со вменяемыми заказчиками. Но это получается не у всех. Гордитесь, что уж там!
                        • 0
                          Не надо так переживать, я просто пытаюсь помочь.
                          Давайте прямо по списку:
                          1) квалификация и опыт это да, чем больше тем лучше, но вполне можно «набить руку» попутно нормально зарабатывая. Если ничего не делать так и навык не появится, так в любой работе.
                          2) время на работу? ну да, время на работу у меня ничем не занято, разве что работой.
                          3) портфолио — как не было так и нет, и наверное уже не будет…
                          4) место физического расположения — см. комментарий выше, не понятно как это связано. Да было бы удобно если бы это был какой-нибудь крупный город, но не критично.
                          5) финансовая обеспеченность опять же не понятно зачем нужна. Если вы тут пишите — значит есть с чего писать, есть интернет и есть свободное время чтоб переписываться в комментариях (к вопросу о пункте 2).
                          6) чувство собственной важности — необходимый в работе фрилансера инструмент, чтоб когда всё-таки докажут что «ты дно» идти и учиться, а иначе лень :)
                          7) про вменяемых заказчиков я писал в комментарии выше, пункт в. Чаще всего попадаются не самые лучшие представители рода человеческого :)
                          Удачи!
                          • 0
                            Не вижу, чем Ваши советы могут мне помочь. По своему опыту так скажу — если ждать у моря погоды пока попадётся вменяемый заказчик с хорошим техническим заданием (а Вы сами согласились, что это не чаще всего происходит), или пока упадёт нормальный проект на фриланс-бирже, то процесс ожидания-поиска может затянуться на очень неприличное время, а жить на одну зарплату в моём месте проживания как-то ну совсем печально. А потому зачастую приходится брать и работу без нормальных технических заданий, и учитывать то, что пока ещё нельзя использовать новые технологии в виде php7 (речь у нас о нём вообще-то изначально велась), потому что хостеры долго раскачиваются и нельзя быть уверенным, в какие непреодолимые требования упрёшься в ближайшем будущем по комплексу абсолютно разнообразных причин.
              • 0
                С дроплетами на океане вообще замечательно — оно конечно удобно, но часто надо отдавать всё уже в готовом виде. «Отдавать» при этом подразумевает абсолютно всё сразу, включая новую почту для клиента (потому что клиент не будет разбираться как регистрироваться на digitalocean), и уже зарегистрированный домен и работающий дроплет. С учётом требования digitalocean привязывать карточку, кейс моментально становится труднореализуемым.
  • 0
    APCu еще не доделали, режим обратной совместимости отваливается. На запуск 5.6 проекта на 7RC ушло пару часов включая сборку, настройку и борьбу с изменениями. Самое коварное — изменение про то, как обрабатываются переменные переменные. Запись $this->$store['key'] в семерке считается как $this->{$store}['key'], а было — $this->{$store['key']}. И есть библиотеки, которые на это полагались.
    • +2
      Запись $this->$store['key'] в семерке считается как $this->{$store}['key'], а было — $this->{$store['key']}

      Когда я читал про эти изменения, я даже удивлялся, это ж каким надо быть мудаком, чтоб такую неоднозначную нотацию использовать.
      Дайте уже фамилий авторов, чтоб я таки это знал.
      • +1
        Ну, Doctrine1 например, в трёх местах :)
  • +8
    Александр, а пробовали Yii под этим запускать?

    Я просто на ночь глядя попробовал поднять(завелось влет, одно место в коде поправить пришлось) и несколько недоумеваю: в простом синтентическом тесте — есть прирост в скорости, но вот сам yii (что первый что второй) показывает очень большое падение скорости — раза в 2.

    Возможно у нас в проекте что-то лишнее есть, но я уж попробовал совсем все собственное отключить, оставив почти пустую страницу — получил еще большее падение, раз в 10. Конфиги и код, одинаковые. БД не влияет совсем

    yadi.sk/i/ryRUbfxGktfa8 — yii2 на 5.5.9 — 14 мс
    yadi.sk/i/4QK3FliqktfaQ — yii2 на 7.0.1 — 199 мс

    yadi.sk/i/CZ9L7vWgktfbN — yii1 на 5.5.9 — 0.05с
    yadi.sk/i/imjZjhMtktfc3 — yii1 на 7.0.1 — 0.29с

    да и по памяти в обоих случаях хуже. Возможно это у меня проблемы с проектом, или php нормально не настроил. Вопрос один — вы yii пробовали под ним заводить? должно стать быстрее?
    • 0
      Присоединяюсь к вопросу.
    • +10
      Проверьте, включен ли кеш опкода.
      • +7
        Вы правы, дело в этом было.
        Мне почему-то казалось что в php7 opcache не является extension'ом

        После включения — php7 быстрее. на приведенных тестах (где только ядро загружается) разницы практически нет. а вот на реальных страницах — примерно в 1.5 раза
    • 0
      Пробовал. Про OpCache уже ответили.

      Вообще меня немного удивило, что семёрка не дала самому фреймворку очень большого прироста производительности. Видно, у нас и так всё неплохо было :)
      • 0
        А у вас есть цифры по разнице 7 и 5 в yii? какая разница должна быть при оптимальных установках и т.п.
        • +1
          Нормальных цифр нет. Гонял на локальной машине. Много чего могло повлиять. Надо как-нибудь взять чистенький инстанс среднего размера на DigitalOcean и сделать нормальный тест.
      • 0
        профит от PHP7 заметно проявляется когда надо работать со структурами данных, много инстанцирования объектов, графы и т.д. Насколько я помню код Yii там всего этого… и нет почти. А вот штукам типа Doctrine2 с его unit-of-work это должно сильно помочь, но у меня руки не доходят погонять бенчмарки.
        • 0
          Это да. Надо ещё погонять, но если это действительно так, можно, наконец, типизировать конфиги. Конечно, это не подойдёт для любителей yaml, но направление занятное.
  • +2
    Переходить стоит, т.к. авторы PHPNG в своих докладах чаще сравнивают производительность не с предыдущими версиями PHP, а HHVM. Т.е. прирост производительности на некоторых задачах может быть существенным.
  • 0
    Rasmus в своем твиттере написал, что если не будет глобальных страшных багов, то семерка выйдет 3 декабря.
    • 0
      И это будет именно этот тегнутый релиз.
  • –6
    Phalcon + php7 = мейнстри́м в ближайшее время )
    • +5
      Пока еще Phalcon мейнстримом стать не может. Быстрым да. Но массовым пока еще нет. И станет ли тоже под вопросом.
      • –2
        А чего не станет? Прекрасный фреймворк, с которым приятно работать. А производительность идет скорее приятным бонусом.
        • 0
          Зефир.
          • 0
            А что зефир? Я сколько с фалконом работаю, мне не приходилось с ним работать. В том смысле, что не было необходимости, а не потому что я про зефир не знаю. То есть зефир отдельно, фалкон как фреймворк отдельно. (И да я в курсе что 2 версия фалкона на зефире написана)
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Рано или поздно натыкаешься на баг, который надо пофиксить край вчера потому что он в продакшне. Надеяться на команду фреймворка уже некогда. С PHP фреймворками тут всё просто: воспроизвёл локально, пробежался XDebug-ом, поправил, влил на сервер, отправил pull-request в upstream.

              С фальконом так не выйдет.
              • 0
                Может я что не понимаю, но почему с фальконом не выйдет? Только из-за того что одного XDebug может оказаться недостаточно?
                • +2
                  Ну да. Радость учить ещё один язык, делать билд и дебажить через strace не все хотят познать.
                  • +2
                    Как будто бы дебажить PHP через strace не приходилось. Но в целом я согласен, фалькон вносит дополнительные риски. Сегодня ты радуешься что у тебя все быстро работаешь а завтра нанимаешь Сишника.
                    • 0
                      Какого сишника, исходники в зефире на гитабе — идите и смотрите логику.
                      Синтаксис — тот же пэхапэ.
                      Или вы все еще на 1.3?
                      • 0
                        Или вы все еще на 1.3?

                        я не использую фалькон и не вижу в нем смысла. Мне проще узкие места переписать на golang а проблему с оверхэдом бутстрапинга фреймворка невилировать решениями типа php-pm.

                        И таки зефир не решает проблему дебага. Сишника нанимать придется потому что нанять php-ника который шарит в gdb выйдет сильно проблематично (банально меньше таких), а зефирка всеравно сначала транспайлится в Си.
                      • 0
                        Мы про дебаг.
                  • 0
                    strace поможет только при дебаге наружу, к системе.
              • 0
                Отнаследоваться от бажного класса и запилить свой метод поверх бажного. Не всегда применимо конечно, но возможно же.
                • 0
                  Это вариация спартанского дебага через var_dump. Возможно, но в сравнении с XDebug, очень неудобно.
        • 0
          А кто говорит, что плохой? Мне тоже нравиться. Массовым (т.е. мейстримом) ему не светит стать ближайших лет 5. А может быть и никогда. И дело не во фрейворке, а в людях. Массам сложно уловить концепт. Лучшие практики тоже пока не очень наработаны, имхо. Скажем так, он инфраструктурно сыроват.

          Вот если команда будет вести разъяснительную деятельность, то да, шансы есть. Сравниваю на примере Yii. А так… он так и останется уделом небольшой группы энтузиастов (которые его умееют готовить) и гиков.
          • 0
            Повторюсь, я не имел ввиду сейчас.
            Массовость значительно возросла в последне время, все будет, ждемс )
            Разъяснительные работы тоже едутся, ищите видео с конференций.
            • 0
              Не, ну больше народу будет однозначно. Фреймворк достойный. Работы тоже отлично ведутся. Сергей Яковлев — хороший докладчик.
      • 0
        Массовым уже становится, а про мейнстрим я же написал — в ближайшее время, а не сейчас.
        Я все свои проекты перевел и новые на нем ввожу, нет пока на горизонте конкурентов, да если и будут то портирвоанные версии, если сделают автоматический конвертер в зефирную версию.

  • 0
    Сайты на Wordpress можно безболезненно переводить?
    • +2
      Сам Wordpress вроде да. Плагины — не факт.
  • +2
    Используем yii1 в работе.На продакшене еще не тестировали, но на сервере разработки прирост производительности около 25%. Выигрыш по памяти около 80-90%. Все цифры конечно примерные, но показывают общую картину.
    • +2
      Да, забыл отметить, что сравнивали семерку с 5.6 веткой. У нас 5.6 прибавил в скорости по сравнению с 5.4 около 10%.
  • +1
    Уже переходим, причём с 5.3
  • 0
    Вот только сегодня делал сборку с гита. На входе 7.1.0, всё собралось без единого каприза, чекинстал, деплой, всё работает. По сравнению с предыдущими версиями намного ( это минимум 20-30%% ) выросла производительность.
  • +2
  • 0
    Async/await мы, видимо, дождемся еще только годика через два. Хотя уже вон и JS и даже Python подтянулись. А ведь это новая the big thing в веб-программировании.
    • +1
      новая the big thing в веб-программировании


      это синтаксический сахар над промисами с использованием генераторов, по сути. В c# эта штука есть уже давольно таки давно.

      В целом в php вы с версии 5.5 можете использовать корутины, есть даже отдельные библиотеки, которые демонстрируют нам то же что и async/await (лишь с небольшими ограничениями и чуть более сложной семантикой). Примерно так же работают полифилы для js.

      Занимательно то, что подобные идеи были описаны еще для PHP6, но что-то пошло не так. В целом рекомендую почитать эту дискуссию из php internals что бы примерно понять на каком мы свете относительно async/await.
      • +1
        это синтаксический сахар над промисами с использованием генераторов

        Нет. И нежелание осознавать это отличие может привести язык к большой беде (проигрыш в конкуренции с другими языками).

        Вернее, технически — это, конечно, синтаксический сахар. Точно так же, как любой язык программирования высокого уровня есть лишь синтаксический сахар над ассемблером.

        Концепция генераторов — это «выпихивание» наружу некоторых значений с сохранением контекста (понятна 90% программистов) и концепция «впихивани» данных обратно (понятна уже только 10% из них — все IMHO, естественно).

        Концепция промисов — это концепция отложенных вычислений.

        В то же время, async/await — это концепция «выпрыгивания наружу, когда хочется заблокироваться» и «впрыгивания внутрь, когда можно разблокироваться». Это впрыгивание и выпрыгивание контролируется не столько программистом, сколько планировщиком (довольно сложным). Более того, async/await — это также концепция для объединения несколких однотипных операций в пачки для последующей их «пачечной» обработки. Да, с точки зрения кода интерпретатора там переиспользуется код для генераторов (в части сохранения контекста и «впрыгивания») и способ работы с промисами, но с точки зрения программиста-пользователя все это оказывается за кадром (точно так же, как ассемблер остается за кадром для большинства си-программистов). Также async/await (на уровне пользователя) понятен с первого же раза 100% программистов — они просто начинают писать код в новом стиле, не задумываясь, как он работает «под капотом».
  • +2
    Протестировал на одном из своих проектов, к сожалению, PHP 7.0.0 не показал повышения производительности, есть даже небольшое падение.

    Отключил memcached, прогнал на главной странице (анонсы всех разделов сайта, порядка 80 тяжелых запросов с сортировкой ~ 50 000 записей в бд)

    Потребление памяти значительно снизилось:

    PHP 5.6.1 — 2.411mb
    PHP 7.0.0 — 1.301mb

    А вот время исполнения незначительно ухудшилось:

    PHP 5.6.1 — 0.98560s.
    PHP 7.0.0 — 0.99667s.

    Посмотрел профили XDebug, удалось выяснить некоторые причины.

    — mysqli на PHP 7.0.0 работает немного медленее (практически все функции)
    — md5 работает значительно медленее
    — функции по работе со строками немного просели
    и т.д.



    Таблица с примерами времени исполнения:

    • 0
      Притом падение наблюдается если PHP пришел из реп (в моем случае OpenSuse)
      Если запускать скрипты в официальных образах docker, падения производительности нет.
    • 0
      PHP 7.0.0 не показал повышения производительности


      opcache включен?
      • 0
        И включал и выключал. Результаты схожи. Всего скорее плохая сборка в репо.
        • 0
          самый простой вариант — сравнить phpinfo варианта в контейнере и варианта из репозитория. Так же не стоит забывать что по дефолту в докер контейнере нет xdebug а он сильно влияет на производительность.
          • 0
            XDebug был отключен до профилирования, время схоже.
            Под конец просто тестировал 3000000 md5 в cli. В докер контейнере результат PHP 5.6.1 cхожий с докер 7.0.0 и 5.6.1 из suse репозитория. А вот PHP 7.0.0 из репо отстает 20с против 5с, явно собрали с разными флагами.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.