Влияют ли комментарии на производительность?

Правильно ли мне сказать, что код JavaScript не скомпилирован, даже JIT? Если это так, значит ли это, что комментарии влияют на производительность, и я должен быть очень осторожным, когда я размещаю свои комментарии? Например, размещать комментарии к функциям выше и вне определения функции, когда это возможно, и определенно избегать размещения комментариев внутри циклов, если я хочу максимизировать производительность? Я знаю что вmost В случаях (по крайней мере, в случаях без циклов) изменение производительности будет незначительным, но я думаю, что это было бы полезно знать и знать, особенно для разработчиков front-end / js. Кроме того, был задан соответствующий вопрос относительно оценки, которую я недавно провел.

 Jamund Ferguson19 апр. 2012 г., 19:01
Стоимость комментариев в не минимизированном источнике в 1000 раз меньше стоимости разработчиков, не знающих, что происходит!
 Conrad Frix19 апр. 2012 г., 18:59
Итак, когда вы проверили это, каковы были ваши результаты?
 Alexey Lebedev19 апр. 2012 г., 18:59
Каждый файл анализируется только один раз, когда он загружен. Таким образом, не имеет значения, находится ли комментарий внутри или снаружи функции, интерпретатор его не видит.
 Anurag Uniyal19 апр. 2012 г., 18:57
Это будет зависеть от браузера, я думаю, что Chrome V8 имеет JIT-компилятор
 Nick Rolando19 апр. 2012 г., 19:24
@AlexeyLebedev Понятно, спасибо. Я так понимаю, что это тоже касается петель :)

Ответы на вопрос(3)

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

 Nick Rolando19 апр. 2012 г., 19:36
Спасибо, я обязательно посмотрю минимизаторы.

хотя (даже IE6 обрабатывает комментарии правильно!to be confirmed...).

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

Также:

V8 increases performance by compiling JavaScript to native machine code before executing it.

Источник

 19 апр. 2012 г., 19:40
Да, добавил это в мой ответ :) Википедия.
 Nick Rolando19 апр. 2012 г., 19:37
Спасибо. Не могли бы вы предоставить ссылку на вашу цитату?
 17 нояб. 2015 г., 10:18
Помните, что вам может быть запрещено удалять комментарии из библиотек, которые вы используете, поскольку они часто также содержат информацию о лицензировании.
Решение Вопроса

t compiled, not even JIT?

Нет. Хотя JavaScript традиционно является «интерпретируемым» языком (хотя это не обязательно должно быть), большинство движков JavaScript компилируют его на лету, когда это необходимо. V8 (движок в Chrome и NodeJS), используемый для немедленной и быстрой компиляции, а затем возврата и агрессивной оптимизации любого используемого кода (старый стек FullCodegen + TurboFan); Некоторое время назад, сделав много реальных измерений,они переключились Первоначальный разбор до byteocde и интерпретация, а затем компиляция, если код вообще многократно используется (новый стек Ignition + TurboFan), получая значительную экономию памяти, не компилируя однократный код установки. Даже движки, которые менее агрессивны, почти наверняка, по крайней мере, анализируют текст в какой-либо форме байт-кода, отбрасывая комментарии рано.

Помните, что & quot; интерпретировано & quot; против & quot; скомпилированного & quot; обычно больше относится к окружающей среде, чем к языку; Есть интерпретаторы C, и есть компиляторы JavaScript. Языки, как правило, тесно связаны со средами (например, как JavaScript имеет тенденцию связываться со средой веб-браузера, даже если он всегда использовался более широко, даже в 1995 году), но даже тогда (как мы видели) ), может быть вариация.

If so, does that mean that comments have an affect on performance...

Очень, очень,very минимальный, на начальном этапе разбора. Но комментарии очень легко сканировать в прошлом, не о чем беспокоиться.

Если вы действительно беспокоитесь об этом, вы можете минимизировать свой скрипт с помощью таких инструментов, какjsmin илиЗакрытие Компилятор (даже с простой оптимизацией). Первый просто лишит комментариев и лишних пробелов, и тому подобное (все еще довольно эффективно); последний делает этоand на самом деле понимает код и делает некоторые вставки и тому подобное. Таким образом, вы можете свободно комментировать, а затем использовать эти инструменты, чтобы гарантировать, что любое незначительное влияние, которое эти комментарии могут оказать при первой загрузке скрипта, будет обойдено с помощью минимизирующих инструментов.

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

Here's an experiment which (in theory) reparses/recreates the function every time Here's one that just parses/creates the function once and reuses it

Результат? Мое предположение состоит в том, что в погрешности измерения теста нет заметной разницы.

 18 июл. 2012 г., 21:10
вау, честная игра для тестов! Они подтвердили то, что я уже знал. Если люди беспокоятся о производительности, им, вероятно, следует оставить старших братьев, таких как jQuery, Tinymce и другие, которые импортируют десятки тысяч строк кода js. Несколько комментариев не могут превзойти те, что убивают производительность.
 Nick Rolando19 апр. 2012 г., 19:31
Круто, спасибо. Очень информативно.

Ваш ответ на вопрос