Я всегда (ну стараюсь) комментировать мой код. Я настроил свой сервер для удаления этих комментариев/лишнего пробела перед доставкой. Было бы лучше не иметь комментариев в коде живых систем (Javascript/php) и, следовательно, уменьшить эти накладные расходы или удалить или интерпретировать?
Если да, то как я могу получить торт и съесть его?
Для PHP это не имеет значения. Ваш PHP-код не отправляется в браузер.
Для JavaScript рекомендуется минимизировать код. Это уменьшает размер, изменяя имена переменных, удаляя пустое пространство и удаляя все комментарии. Для этого есть несколько онлайн-инструментов, которые часто доступны в вашей среде IDE.
Независимо от того, что вы делаете, оставьте свой код прокомментированным, где вы его работаете. Не удаляйте комментарии от PHP и не уменьшайте свой JS вручную.
Хотя общее предположение состоит в том, что если PHP-пережевывание через комментарии вызывает отсутствие измеримой разницы, лучше проверить его, не так ли?
(Обратите внимание: по здравому смыслу мы ожидаем, что обработка чистого запроса, управление разрешениями, управление процессом, отправка этого, делегирование этого, запуск среды выполнения PHP, управление различными кешами, ведение файлов активов, общий диск и сетевые операции ввода/вывода и т.д., oh и BTW, также выполняющие код, все это, скорее всего, намного больше, чем любое большое количество комментариев.)
Итак, я дал ему очень простой путь, чтобы мгновенно почувствовать это.
Предсказание "влияния комментариев" так сложно обнаружить как нейтрино, я был преднамеренно после слегка патологической установки, пытаясь сделать разница измерима, но все же не слишком чрезмерна.
Я создал два файла. Один без комментариев, всего ~ 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 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-процесса, и многое из-за пределов его, посредством отдельных исполнений, чтобы принудительно переназначить, что является единственной интересной частью этого эксперимента.
Для самых быстрых результатов я сделал несколько shell:
#!/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, маскируя малейшее время разбора комментариев.)
Запуск 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
Как вы можете видеть, все это мусор... Но если мы игнорируем колебания окружающей среды, вывод заключается в использовании большего количества комментариев, это сделает ваш script быстрее!:)
(Некоторые шумы были вырезаны из выходов 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
(BTW, не спрашивайте меня, почему ответы без 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
ОК, осознав, что я оставил кеш, я прокомментировал расширение из конфигурации 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
Итак... Наконец, цифры! Ну, бесполезный мусор, по сути, но, по крайней мере, не просто спекуляции с религиями. Чувствовать себя намного лучше, чем просто смутить, из-за разумной причины путать данные, чем с отсутствием!:)
Теперь, после того, как я, конечно, потратил больше времени на это, ответ на давний вопрос о том, "сколько комментариев стоит", остается загадкой.
Поскольку нейтрино (невероятно) были обнаружены в течение многих лет, мы можем с уверенностью начать смущаться. Кто-то в конечном итоге приведет к прорыву и, наконец, обнаружит влияние комментариев к PHP? Никто не знает...
Если вы хотите улучшить производительность своего PHP-приложения, вам следует использовать байт-код, например XCache или APC.
Таким образом, сервер не должен анализировать PHP-код для каждого запроса. Конечно, ваш сервер должен поддерживать такое расширение.
Что касается удаления комментариев: я не уверен, что это имеет огромное значение (кроме ваших комментариев).
Да, это влияет! В этом нет никаких сомнений.
Каждый раз, когда PHP должен интерпретировать код, который НЕ каким-то образом кэшируется, операция ввода-вывода занимает больше времени, если ему нужно прочитать больше данных с диска.
Сама интерпретация (если она не кэширована так или иначе) занимает больше времени.
Снижение производительности очень сильно зависит от используемой файловой системы и кешей. Возможно, это не так важно в вашем конкретном случае.
В веб-среде, которую мы написали, когда мы упаковываем файлы дистрибутива для использования в производственной среде, мы специально удаляем все комментарии, чтобы убедиться, что LIVE-приложения не наказываются нашими много комментариев (обычно исходный файл наших подпрограмм "String" составляет около 169 КБ, прежде чем удалять комментарии, и только для 46 Кб после обработки).
Мы отказались от попыток измерить реальный штраф, поскольку было невозможно справиться с различными средами, файловыми системами и механизмами кэширования. Поэтому мы решили распространить наш код в двух вариантах: с комментариями и без комментариев.
у вас могут быть комментарии в ваших php файлах, но я не рекомендую использовать тонны комментариев в Javascript.
PHP работает на сервере, поэтому сервер может легко обрабатывать файлы php с комментариями.
Это делает разницу в JavaScript, поскольку вы хотите отправить меньше данных в браузер, но в php это просто не имеет значения. Для комментариев нет комментариев, поскольку компилятор их игнорирует. Для Javascript вы хотели бы иметь копию вашего обычного файла с комментариями .js, но они всегда запускают его через minifier и создают yourscript-min.js для создания.
Когда вам нужно внести изменения в свой script, просто измените свой обычный script, а затем заново создайте мини-версию. Используйте только модифицированную версию.
Опять же, для 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 файлы и сжимать по требованию.
Совершенно очевидно, что это может повлиять на ОГРОМНЫЙ трафик, но абсолютное незначительное значение для большинства настроек. Подумайте о сайте, где у вас есть 1mil. параллельные соединения и веб-приложение (например, CMS, такие как Joomla, у которого много файлов php и большая часть комментариев) запрашивают для каждого соединения эти несколько сильно прокомментированных и отступов php файлов. Минимизирует ли каждый php файл приложения разницу? Я думаю, это определенно может, если у вас нет любого кэширования включенного. Это просто базовый материал ввода-вывода, чем меньше вы делаете свой файл, тем меньше памяти потребуется для его загрузки/обработки.