Комментирование интерпретируемого кода и производительности

Я всегда (ну стараюсь) комментировать мой код. Я настроил свой сервер для удаления этих комментариев / лишнего пробела перед доставкой. Было бы лучше не иметь комментариев в коде живых систем (Javascript / php) и, следовательно, уменьшить эти накладные расходы или удалить или интерпретировать?

Если да, то как я могу получить торт и съесть его?

Для PHP это не имеет значения. Ваш PHP-код не отправляется в браузер.

Для JavaScript рекомендуется минимизировать код. Это уменьшает размер, изменяя имена переменных, удаляя пустое пространство и удаляя все комментарии. Для этого есть несколько онлайн-инструментов , и это часто доступно в вашей среде IDE.

Независимо от того, что вы делаете, оставьте свой код прокомментированным, где вы его работаете. Не удаляйте комментарии с PHP и не уменьшайте JS вручную.

Хотя общее предположение заключается в том, что наличие переименования PHP через комментарии не вызывает заметной разницы , лучше проверить его, не так ли?

(Обратите внимание: по здравому смыслу мы ожидаем, что чистая обработка запросов, управление разрешениями, контроль процесса, отправка этого, делегирование этого, запуск среды выполнения PHP, управление различными кешами, ведение файлов активов, общий диск и сеть I / O и т. Д., Oh и BTW, также выполняющие код, все это, скорее всего, значительно больше, чем любое большое количество комментариев.)

Поэтому я дал ему очень простой способ, чтобы мгновенно почувствовать это.

1. Настройка

Предсказание «влияния комментариев» так же трудно обнаружить, как нейтрино , я был преднамеренно после слегка патологической установки, пытаясь измерить разницу, но все же не слишком чрезмерно нереалистичен.

Я создал два файла. Один без комментариев, всего ~ 100 байт, прямо к точке, no-comments.php :

 <?php function task() { ++$GLOBALS; echo "[$GLOBALS] Lorem ipsum dolor sit amet cosectetur...\n"; } 

И еще, ~ 60K (пребывание под 64K только для суеверия, связанного с кучей), comments.php :

 <?php /* ... some 30K comments ... */ // OK, that's something, but how about: /* ... same 30K comments again ... (Phantomjs changelog, for the curious of you. :) ) */ // Finally, do something: function task() { ++$GLOBALS; // Comments are cheap, so let me tell you how much I enjoyed this instead of properly declaring a counter. :) echo "[$GLOBALS] Lorem ipsum with a lot of comments...\n"; } 

Примечание: это, конечно, очень вероятно, повлияет на размер файла на самом деле, а не только на комментарии, но это всегда неотъемлемая часть «комментариев (не)», и я тоже хотел сначала что- то сделать . Возможно, даже это уже неизмеримо, не так ли?

Общая идея состояла в том, чтобы скомпилировать task() по-разному, всего лишь бит (или вообще ничего) изнутри одного и того же процесса PHP, и многое из-за пределов этого, посредством отдельных исполнений, для принудительной репарации, которая является единственной интересная часть этого эксперимента.

Для самых быстрых результатов я сделал несколько прогонов оболочки :

 #!/bin/bash for (( i = 0; i < 1000; i++ )) do php comments.php # <-- and another batch with "no-comments.php" done 

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

 #!/usr/bin/php <?php $t1 = microtime(true); for ($i = 0; $i < 1000; ++$i ) { system("php comments.php"); // <-- and with "no-comments.php" } $t2 = microtime(true); echo "Time: ", $t2 - $t1 

Для HTTP-прогонов я добавил этот index.php :

 <?php $GLOBALS = 0; // innovative use of a dull language feature ;) $t1 = microtime(true); require_once (isset($_GET['no']) ? 'no-' : '') . 'comments.php'; // Played a bit with looping here, but ended up leaving it out. // for ($i = 0; $i < 3; ++$i) { // task(); // echo '<br>'; // } $t2 = microtime(true); echo "<hr>Time: ", number_format($t2 - $t1, 10); 

Обратите внимание: сначала, к сожалению, я оставил PHP Zend Opcache включенным и потратил много времени, пытаясь разобраться в результатах …; -o Затем я отключил кеш, конечно, и повторил веб-тесты ( только ) ,

Хост – это просто ванильный Debian, Apache2 с некоторым PHP5 (я думаю, это FPM – даже не потрудился проверить, так как это должно быть ортогонально субъекту тестирования (пожалуйста, исправьте меня, если это неверно). на самом деле даже помогают разоблачить разницу, уменьшив несущественные накладные расходы на запуск PHP, кропотливое время синтаксического анализа комментариев.)

2. Результаты – оболочка:

Запуск PHP-cli был на удивление медленным, поэтому мне стало скучно, после всего лишь дюжины циклов из 1000 итераций для обоих вариантов. (Результаты в секундах.)

КОММЕНТАРИИ:

+44,2015209198
+39,710990905762
+42,374881982803
+36,29861998558
+44,764121055603
+38,85772395134
+42,627450942993
+38,342661142349
+48,539611816406
+39,784120082855
+50,34646987915
+47,782819032669
+36,974604845047
+45,692447900772

СРЕДНЕЕ: 42.592717

БЕЗ КОММЕНТАРИЕВ:

+45,617978811264
+43,397685050964
+46,341667175293
+44,246716976166
+40,348230838776
+43,048954963684
+38,57627081871
+50,429704189301
+41,811543226242
+35,755078077316
+53,086957931519
+31,751699924469
+48,388355970383
+49,540207862854

СРЕДНЕЕ: 43.738647

Как вы можете видеть, все это мусор … Но если мы игнорируем экологические колебания, вывод заключается в использовании большего количества комментариев, это сделает ваш скрипт быстрее ! 🙂

3. Результаты – HTTP, Zend Opcache:

(Некоторые шумы были отключены от выходов ab).

КОММЕНТАРИИ:

ab -qd -n 10000 'http://.../comments/?yes'

 Server Software: Apache/2.4.10 Concurrency Level: 1 Time taken for tests: 3.158 seconds Complete requests: 10000 Failed requests: 0 Non-2xx responses: 10000 Total transferred: 7120000 bytes HTML transferred: 4620000 bytes Requests per second: 3166.12 [#/sec] (mean) Time per request: 0.316 [ms] (mean) Transfer rate: 2201.45 [Kbytes/sec] received 

БЕЗ КОММЕНТАРИЕВ:

ab -qd -n 10000 'http://.../comments/?no'

 Server Software: Apache/2.4.10 Concurrency Level: 1 Time taken for tests: 3.367 seconds Complete requests: 10000 Failed requests: 0 Non-2xx responses: 10000 Total transferred: 7120000 bytes HTML transferred: 4620000 bytes Requests per second: 2969.95 [#/sec] (mean) Time per request: 0.337 [ms] (mean) Transfer rate: 2065.04 [Kbytes/sec] received 

Вау! : -o Так же, как работает раковина! 🙂 ОК, не веря своим глазам, я повторил это еще несколько раз, пока это не имело смысла … 🙂 Видишь? Вот:

 Benchmarking ...<"NO COMMENTS">... (be patient).....done Time taken for tests: 2.912 seconds Total transferred: 7120000 bytes HTML transferred: 4620000 bytes Requests per second: 3433.87 [#/sec] (mean) Time per request: 0.291 [ms] (mean) Transfer rate: 2387.61 [Kbytes/sec] received 

(Кстати, не спрашивайте меня, почему ответы без 2xx. Через Интернет они были 200 OK).

Затем, в десять раз больше итераций:

КОММЕНТАРИИ:

 Time taken for tests: 32.499 seconds Requests per second: 3077.04 [#/sec] (mean) Time per request: 0.325 [ms] (mean) Transfer rate: 2139.51 [Kbytes/sec] received 

БЕЗ КОММЕНТАРИЕВ:

 Time taken for tests: 28.257 seconds Requests per second: 3538.92 [#/sec] (mean) Time per request: 0.283 [ms] (mean) Transfer rate: 2460.66 [Kbytes/sec] received 

Фу, отлично! Комментарии – зло! 😉

Ну, я все еще сделал еще пару, и я могу только показать вам этот результат без комментариев, строго от записи:

 Time taken for tests: 37.399 seconds Requests per second: 2673.84 [#/sec] (mean) Time per request: 0.374 [ms] (mean) Transfer rate: 1859.15 [Kbytes/sec] received 

4. Результаты – HTTP, Zend Opcache DISABLED:

ОК, осознав, что я оставил кеш, я прокомментировал расширение из конфигурации PHP-FPM (так, действительно, это то, что работает здесь), перезапустил службы, проверил phpinfo() и собрал новые результаты:

КОММЕНТАРИИ:

 Time taken for tests: 34.756 seconds Requests per second: 2877.23 [#/sec] (mean) Time per request: 0.348 [ms] (mean) Transfer rate: 2000.58 [Kbytes/sec] received 

Еще раз:

 Time taken for tests: 31.170 seconds Requests per second: 3208.24 [#/sec] (mean) Time per request: 0.312 [ms] (mean) Transfer rate: 2230.73 [Kbytes/sec] received 

БЕЗ КОММЕНТАРИЕВ:

 Time taken for tests: 30.060 seconds Requests per second: 3326.70 [#/sec] (mean) Time per request: 0.301 [ms] (mean) Transfer rate: 2313.10 [Kbytes/sec] received 

Еще раз:

 Time taken for tests: 32.990 seconds Requests per second: 3031.23 [#/sec] (mean) Time per request: 0.330 [ms] (mean) Transfer rate: 2107.65 [Kbytes/sec] received 

Что ж. Как вы можете видеть, в основном: нет лишнего отличия от состояния включения / выключения opcache! Также между комментариями вкл / выкл (кроме крошечного намека, но, увидев колебания …)! : -o

5. Вывод

Итак … Наконец, цифры! Ну, бесполезный мусор, по сути, но, по крайней мере, не просто спекуляции с религиями. Чувствовать себя намного лучше, чем просто смутить, из-за разумной причины путать данные, чем с отсутствием! 🙂

Теперь, после того, как я, конечно, потратил больше времени на это, ответ на давний вопрос о том, «сколько комментариев стоит», остается загадкой.

Поскольку нейтрино были (невероятно) обнаружены в течение многих лет, мы можем с уверенностью начать чувствовать себя смущенными. Кто-то в конечном итоге приведет к прорыву и, наконец, обнаружит влияние комментариев к PHP? Никто не знает…

Если вы хотите улучшить производительность своего PHP-приложения, вам следует использовать байт-код, например XCache или APC .

Таким образом, сервер не должен анализировать PHP-код для каждого запроса. Конечно, ваш сервер должен поддерживать такое расширение.

Что касается удаления комментариев: я не уверен, что это имеет огромное значение (кроме ваших комментариев).

Да, это влияет! В этом нет никаких сомнений.

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

Сама интерпретация (если она не кэширована так или иначе) занимает больше времени.

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

В веб-среде, которую мы написали, когда мы упаковываем файлы дистрибутива для использования в производственной среде , мы специально удаляем все комментарии, чтобы убедиться, что LIVE-приложения не наказуются нашими многочисленными комментариями (как правило, исходный файл нашего Процедуры «String» составляют около 169 КБ, прежде чем удалять комментарии, и только для 46 КБ после лечения).

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

Это имеет значение для JavaScript, поскольку вы хотите отправить меньше данных в браузер, но в php это просто не имеет значения. Для комментариев нет комментариев, поскольку компилятор их игнорирует. Для Javascript вы хотели бы иметь копию своего обычного файла с комментариями .js, но они всегда запускают его через minifier и создают yourscript-min.js для производства.

Когда вам нужно внести изменения в свой скрипт, просто измените свой обычный сценарий, а затем заново создайте мини-версию. Используйте только продуманную версию.

Опять же, для php это не имеет значения, только для Javascript, а также для html-файлов.

Лучше удалите все комментарии js-файлов и даже используйте инструмент minifier. Уменьшение размеров файлов js уменьшает время загрузки страницы на клиенте (так как ему необходимо загрузить потом) и стоит меньше полосы пропускания (учитывая, кто платит за это).

Если у вас есть что-то настроенное в вашей системе, чтобы «сжать» ваш javascript «на лету», есть несколько попыток сделать это. Я на самом деле реализовал это с помощью .htaccess, и вы можете получить ОГРОМНУЮ прирост производительности и прокомментировать код на самом сервере.

Я использовал инструменты закрытия Google (файл jar на сервере) и запускал закрытие, если md5_file () в PHP появляется как другое.

Затем я использовал etags для назначения тега этому файлу. Я также кэширую этот файл.

Я также возвращаю 304, не измененный, когда совпадают этиги. Если это не так, я возвращаю новый файл и обновляю users etag. Это КРИТИЧЕСКИЙ, потому что, если вы вернете 200 / OK, вы снова передадите весь файл.

Ключевым моментом здесь является то, что вы теряете производительность, если сжимаете «на лету», потому что вы всегда сжимаете и запускаете PHP-код. Вы можете реализовать его правильно, если потратите время на это. Мне лично нравится эта техника, потому что я могу исправить код сервера в реальном времени, не отправляя неминифицированную версию. Производительность «первого запуска» этого метода медленная, но последующие пользователи вытаскивают кешированный файл на сервер, а затем я возвращаю 304, не измененный после этого. Вы должны сделать все это волшебство в сжатом PHP-файле.

Я упоминаю .htaccess тоже здесь, потому что я использую правило перезаписи там и расскажу веб-сайту, какие файлы сжимать, а какие нет. например, mylibrary.jsc сообщает моему сайту, чтобы сжать его с закрытием. yourlibrary.js позволяет мне иметь другие .js-файлы и сжимать по требованию.

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

PHP работает на сервере, поэтому сервер может легко обрабатывать файлы php с комментариями.

Совершенно очевидно, что это может повлиять на ОГРОМНЫЙ трафик, но абсолютное незначительное на большинстве настроек. Подумайте о сайте, где у вас есть 1mil. параллельные соединения и веб-приложение (например, CMS, такие как Joomla, у которого много файлов php и большая часть комментариев) запрашивают для каждого соединения эти несколько сильно прокомментированных и отступов php-файлов. Будет ли минимализирован каждый php-файл приложения? Я думаю, это определенно может быть, если у вас нет какого-либо кэширования . Это всего лишь основной материал ввода-вывода, чем меньше вы делаете свой файл, тем меньше памяти потребуется для его загрузки / обработки.