Comments 13
Спасибо, для меня go довольно новый инструмент, в котором осталось еще много неизведанного. Писал статью в том числе из расчета, что кто-то сможет в комментариях указать на ограничения описанного в статье подхода. Например, интересно насколько большой JSON можно передать в библиотеку и обратно.
Насчет сложности отладки библиотеки на Go - я в этом языке новичок, эти грабли еще ждут меня где-то на дороге приключений.
Тоже проводил подобные эксперименты PHP-> go ext, но пришел к выводу, зачем так заморачиваться, если можно на го написать c 0 или на крайний случай реализовать как внешний сервис с API.
Конечно, практической целесообразности стоит отдавать более высокий приоритет, чем всяким экзотическим решениям. Однако в моем опыте были ситуации и ограничения, когда приходилось идти довольно нетривиальными путями. У меня на примете есть один сценарий, где создание самостоятельного сервиса с HTTP API это перебор, а вот расширение возможностей PHP через c-shared библиотеку может дать достаточный эффект. А пока что эта связка позволяет расширить список профессиональных возможностей. Иметь и не нуждаться часто лучше, чем нуждаться, но не иметь.
Например, FrankenPHP так работает. Заморачиваться определённо стоило.
Там же такие накладные расходы что выхлопа нет
Можете пояснить, про какие именно накладные расходы идет речь? Возможно у Вас был какой-то интересный опыт, который мог бы проиллюстрировать такую позицию?
Да я смотрел предыдущую такую статью с ffi и локально даже воспроизвел. И запустил число дробилку на go что явно шустрее нежели на php отрабатывает. И вот прироста не увидел через ffi
Благодарю за пояснение - это немного прояснило, что имелось в виду. В моем примере есть выигрыш по скорости с 9 секунд до 3 секунд. Мы экономили на асинхронности вызовов. Т.е наш php-скрипт большую часть времени находился бы в состоянии ожидания ответа от внешнего сервиса, на производительность которого мы по легенде повлиять не можем. Если воспроизведете проект из моей статьи (там три команды по сути), то убедитесь, что выигрыш все-таки есть. При этом выигрыш нативной программы на Go будет таким же незначительным. Просто хочу сказать, что современный PHP 8 версии довольно неплох сам по себе. Допускаю, что с в 95% случаях в стандартных проектах это не потребуется никому. Оптимизация работы с базой данных порой даст намного более значительный выхлоп, чем вот эти все танцы с FFI. Пока перспективным вижу возможность в простой параллелизм (pcntl_fork в базовом сценарии что-то распараллелить и потом собрать воедино кажется довольно неуклюжим в моем опыте), а также в оперативку (для создания матрицы из нулей и единиц PHP потребляет довольно непотребное количество памяти, что приходится идти на ухищрения вроде кодирования векторов в строки из символов). Если говорить про ускорение по CPU в режиме один поток, то игра явно не стоит свеч. Пытаться на PHP перегнать нативную программу на Go также смысла нет.
Ну так-то, если в отрыве от контекста, то в PHP есть и fibers и curl_multi. Мне golang помогал нормально с обработкой изображений.
Спасибо, можно было бы добавить тогда еще и pcntl_fork, но мой небольшой опыт работы с ним был неприятным и пока добивался желаемого результата раз десять возвращался к тому, чтобы написать эту часть на go. Хотелось проделать что-то вроде конвейера: читаем CSV-файл на 1млн строк и раскидываем эту работу на несколько воркеров. Задача воркера найти значения, удовлетворяющие регулярному выражению. Крутил, мутил, но по итогу получилось, что вариант решения на PHP+Redis+pcntl(fork, семафоры, 8 воркеров) сработали за 25-26 секунд, а однопоточный вариант на PHP без всего этого влоб (читаем и отдаем) за 0.3 секунды... О причинах этого я догадываюсь, но тоже своего рода урок про принцип KISS (Keep it simple stupid - не пересложняй)
Туториал: использование Go из PHP через FFI