Чистите ли вы комментарии в PHP коде для оптимизации?

Question

[Юрий]

предполагаю что многие меня сейчас будут учить что пхп компилируется в opcode и выполняется уже оттуда, а в опкоде комменты игнорируются.
но есть небольшой нюанс, комменты открывающиеся с /** перед методами и свойствами класса расцениваются как аннотации и могут быть получены через рефлексию, то есть они должны быть в опкоде.

пример

<?php

class A
{
    /**
     * тут много много разного текста
     */ 
    public $a;
}

echo memory_get_usage();

если менять размер текста то потребление оперативной памяти меняется.
если заменить /** на /* то потребление уменьшается и не зависит от размера коммента. то есть коммент не расценивается как аннотация и не компилится в опкод.

PS изначально хотел навести ревизию в папке vendor в симфони, меня напрягает ее размер 150мб на каждый проект, как оказалось можно легко уменьшить до 50 если выпилить не нужные на проде папки типа Tests/Fictures/Docs/.git (размер последнего для некоторых бандлов особенно умиляет). хотя бы размер дистрибутива будет меньше. если выпилить комменты-аннотации, которые зачастую не используются (естественно есть исключения - аннотации которые реально используются), то можно еще и потребление оперативной памяти уменьшить, а также думаю косвенно и скорость улучшится.

поэтому вопрос в заголовке.

может показаться что экономия на спичках, но в симфони сплошь и рядом используются аннотации только лишь в качестве php-doc но с /**. а кода там десятки мегабайт. мне интересно стало сколько оперативки можно этим сэкономить.

Answer 1

[Кирилл Несмеянов]

1) Симфони и так компилит большинство файлов кернела в app[Env]Kernel в папочку app
2) Учитывая что на основе аннотаций у симфони построена значительная часть логики приложения - удаление оных сравнима с удалением исходного кода. Так же будет всё быстрее на 0.001% и точно так же всё поломается
3) Лезть в вендор папки - это верх извращения де-факто

Ну т.д. Подобные мысли - это пережиток времён php 4, сейчас же проще поставить php 7, нежели поганить исходники (которые, между прочим, придётся "чистить" каждые пару недель руками, т.к. обновления ядра никуда не деваются).

А ещё проще отключить какой-нибудь бандл или переписать один тяжёлый sql\dql запрос - по скорости на порядок будет профитнее.

Comments

[Юрий]

привет Кирилл
1) это знаю, но там не все. хотел кстати об этом тоже спросить, не знаешь можно ли управлять этим процессом, указать еще классы которые он бы туда компилил ?
2) тут 2 момента во первых я понимаю что нужно будет тщательно прописывать исключения. но если посмотреть большая часть аннотаций в юзерском коде (AppBundle), разработчики приложений часто выбирают xml/yml вместо аннотаций. во вторых как мы знаем симфони компилит все конфиги неважно в каком виде они находятся в свой внутренний формат и также складываети в кеш, то есть аннотации на проде скорее всего будут не нужны вовсе.
3) я не собираюсь удалять что-то из дев версии и "поганить исходники". это все должно происходить на этапе сборки проекта. как например делается в мире фронтенда, одни полные исходники в дев версии, а на прод все билдится в пару файлов.

например я хочу на базе симфони сделать какой то коробочный продукт типа цмс для домохозяек, заставлять юзеров качать по 200-300 мб как то не айс, особенно если можно сделать 20-30мб напримпер. дело ведь не только в том чтобы один раз скачать, в коробке может быть и автообновление например. если тысяча юзеров надумает обновляться когда выйдет новая версия то серваку возможно не сладко придется. понимаю что zip/gz исходников отчасти решил бы проблему, но отсутствие лишних многочисленных комментов решило бы еще лучше.

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

меня часто жаба душит использовать симфони в мини проектах из-за веса дистриба, приходится silex/slim расчехлять, хотя хочется пользоваться благами цивилизации тоже.

[Юрий]

MaxKorz: да, для рефлексии, я же писал.
меня волнует не скорость, а память, как оператива так и диск. см коммент выше

[Кирилл Несмеянов]

MaxKorz: декларативное программирование не является прямым исполняемым кодом в отличие от императивного. Аннотации являются средствами реализации подходов декларативного программирования, например маппинг данных в сущностях/моделях, роутинг или независимые от самого фрейма подходы, вроде контрактного программирования (ака DbC например в пакете php-deal), включая аспектно-ориентированное программирование. Ну и прочее.

Так что подытоживая, тут вопрос не в спичках. Аннотации довольно давно стали таким же инструментом программирования в современном php, как и сам исходный код и вырезать конкретно куски доков (т.е. входящие в стандарт PSR-5), оставляя логику при этом как минимум каждый месяц и тратить на это неделю времени... Сомнительное удовольствие.

[Юрий]

Кирилл Несмеянов: время тратится один раз - собрать список исключений час и написать скрипт который вырезает комменты при сборке еще полчаса. единоразово, какие месяцы ))) или вы не видели как фронтендеры свои скрипты билдят ))) там вообще в реалтайме на каждое изменение все собирается.

про аннотации все так, что они нужны, но если заглянуть в код то увидим что 90% кода комментов типа
/**
* var ParameterBagInterface
*/
и еще 9% длинные текстовые описания, в начале файлов и в коде.

и еще на проде аннотации уже не используются, может быть за редким исключением (вычисляется опытным путем), они все компилятся в php и складываются в кеш.

[Кирилл Несмеянов]

Юрий: нужно смириться с тем, что симфони очень быстрый и легковесный на небольших проектах, если разработка тяжёлая, то там вклиниваются кернел эвенты, добавляются секюрити, регаются тысячи классов в контейнер и средненький проект начинает весить под 20 метров на запрос, работая со скоростью ленивого осетра.

Т.е. удаление аннотаций - это экономия на спичках, скорости оно не прибавит, т.к. не кешится в исполняемые опкоды. Просто увеличивает объём занимаемой озу и увеличивает время построения AST. Но с таким же успехом можно просто убрать какой-нибудь бандл из проекта. Нужные реальные замеры и тесты, но отличий более чем в 1% я, почти уверен, не будет.

P.S. У фронтэнда своя болячка, там объём кода влияет на скорость по экспоненте. Если бы каждый класс подключался по http, а не брался из файловой системы или оперативы, вот тогда стоило бы думать однозначно на счёт уменьшения их объёма. Так что сравнивать со сборками через gulp\webpack\etc - не корректно.

[AlikDex]

Кирилл Несмеянов: ну, вообще-то есть специальная функция, которая удаляет с пхп файла все пробелы и комментарии, а также лишние символы типа табуляций и переноса строк. Написать сборщик проекта 10 минут делов. Всего-то нужно пробежаться по всем папкам и файлам проекта и подготовить.
php.net/manual/ru/function.php-strip-whitespace.php

[Кирилл Несмеянов]

Юрий: P.P.S всё зависит от класса ридера в контейнере. Если там CachedReader со сборкой в файловую систему - да, на проде оно не будет использоваться и читаться, а будет браться из кеша (пока он существует).

[Кирилл Несмеянов]

AlikDex: повторяю, такой код не будет работать. На аннотации завязано много логики, которую вы этой функцией уберёте.

[Юрий]

Кирилл Несмеянов: меня только прод и интересует, а не собираюсь подрезать дев версию, только прод при сборке.
аннотации нужно обрезать после генерации прод кеша. во вторых есть масса библиотек где парсинг аннотаций не предусмотрен. AppBundle можно вообще не резать, тк кода там меньше относительно AppBundle. и да, конечно нужно будет делать исключения, но это одноразовая работа.

[Кирилл Несмеянов]

Юрий: предлагаю просто протестировать на фейковых файликах, думаю это займёт минут 10, не больше. С другой стороны - что мешает просто отрубить сохранение док-блоков в опкеше? Будет, по-моему, совершенно тот же результат в итоге.

[Юрий]

Кирилл Несмеянов: тестировать надо именно на полной сборке. на фейковом я писал что память меняется (в шапке). вопрос еще в том сколько файлов там подключится для обработки запроса.

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

по поводу оперативы хочется потестить. но нужно тестить на полной сборке симфони с бандлами в более менее реальном проекте. на днях думаю займусь.

[Кирилл Несмеянов]

Юрий: ну на этом тогда мои полномочия - всё. Но я всё же склоняюсь к тому, что уровень поддержки повысится несоизмеримо с выгодами, учитывая что все подобные манипуляции мы уже проходили в 2000х годах, так что настроен крайне скептически.

[Юрий]

Кирилл Несмеянов: симфони кстати при компиляции в кеш app/cache/dev/classes.php
все комменты и аннотации режет. у меня там 163класса.