Комментирование интерпретируемого кода и производительности - PullRequest
12 голосов
/ 11 октября 2011

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

Если так, как я могу взять свой пирог и съесть его тоже?

Ответы [ 9 ]

20 голосов
/ 11 октября 2011

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

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

5 голосов
/ 10 февраля 2017

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

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

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

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

Ух ты!: -о точно так же, как снаряд работает!:) Хорошо, не веря своим глазам, я повторил это еще несколько раз, пока это не имело смысла ... :) Видите?Здесь:

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 в порядке через Интернет.)

Тогда,с десятикратным числом итераций:

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

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 ОТКЛЮЧЕНО:

ОК, после того, как я понял, что оставил кеш, я закомментировал расширение из конфигурации 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!Ни между комментариями вкл / выкл (кроме крошечной подсказки, но увидев колебания ...)!: -о

5.Заключение

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

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

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

2 голосов
/ 11 октября 2011

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

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

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

1 голос
/ 01 апреля 2015

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

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

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

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

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

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

0 голосов
/ 18 ноября 2017

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

0 голосов
/ 11 октября 2011

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

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

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

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

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

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

0 голосов
/ 11 октября 2011

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

0 голосов
/ 11 октября 2011

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

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

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

0 голосов
/ 11 октября 2011

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

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

...