Когда пробелы влияют на производительность?

Question

Это то, о чем я всегда задумывался, так что вот так.

Когда я писал код, меня учили разбивать строки, комментировать их и т. Д., Чтобы улучшить читаемость (как я полагаю, большинство из нас). Я, очевидно, не рассматриваю это как какую-либо проблему, но это заставило меня задуматься, если компилятор / интерпретатор игнорирует все эти пробельные и прокомментированные разделы или что-то еще, насколько это влияет на его производительность?

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

Тогда я подумал, что насчет пробелов или комментариев на экстремальных уровнях? Скажем, их миллионы или миллиарды?

Полагаю, я задаю вопрос: в какой момент (т. Е. Крайний уровень) игнорируемые участки кода будут влиять на способность компилятора / интерпретатора производить своевременный результат и, следовательно, влиять на работу пользователя?

Спасибо.

Answer 1

Это не повлияет на скомпилированные данные, как следует из слова. Однако не комментируйте понос, это повлияет на производительность других программистов.

Answer 2

Попробуйте это:

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

Редактировать для комментария.

Простой пример использования мира приветствия в Схеме с различными миллионами строк комментариев:

netbsd1# ls -l file* 
-rw-r--r--  1 root  wheel        1061 Mar 11 00:01 file.out
-rw-r--r--  1 root  wheel      102041 Mar 11 00:01 file1.out
-rw-r--r--  1 root  wheel    10200041 Mar 11 00:01 file2.out
-rw-r--r--  1 root  wheel  1020000041 Mar 11 00:03 file3.out
netbsd1# for i in file*
> do
> echo $i
> time ./scm $i
> done
file.out
hello world
    0.06s real     0.01s user     0.01s system
file1.out
hello world
    0.03s real     0.01s user     0.02s system
file2.out
hello world
    0.64s real     0.28s user     0.30s system
file3.out
hello world
   61.36s real    11.78s user    41.10s system
netbsd1# 

Очевидно, что файл размером 1 ГБ оказал большое влияние, что не обязательно удивительно, учитывая, что у меня только 512 МБ ОЗУ на этом устройстве.

Кроме того, это скорость интерпретации / компиляции. Если вы на самом деле скомпилировали эти файлы, все среды выполнения были бы идентичны. Вы можете сделать свои собственные выводы, определяющие влияние.

Answer 3

Это зависит.

В скомпилированных языках компиляция может занять больше времени, но вам, вероятно, все равно, поскольку это делается один раз.

В интерпретируемых языках время загрузки будет напраснымвремя выполнения и большее использование памяти, если интерпретатор сохраняет текст в памяти.

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

Для кода с чрезмерным количеством комментариев, страдающего от комментариев, генерируемых генераторами кода, чрезмерноРевностные системы контроля версий и «религиозные комментаторы», я бы на самом деле больше беспокоился о бедном читателе / ​​рецензенте, которому приходится разбираться со всем этим в основном бесполезным и, возможно, несинхронизированным текстом, чтобы добраться до кода.

Answer 4

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

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

Answer 5

Компиляция (и связывание) - это фаза 1.

Выполнение - это фаза 2.

Поскольку фаза 1 имеет значение не менее O (длина входа), можно ожидать, что фаза 1 займет пропорциональное время (по крайней мере) к длине ввода.Если длина файла меньше 10 ^ 4 строк, это, вероятно, не будет беспокоить вас слишком сильно.Если длина файла составляет 10 ^ 12 строк, это может занять годы, если что-то не сломается первым.

Но это не повлияет на этап 2. Что влияет на этап 2, так это то, сколько работы выполняет программа и сколькодля этого нужно .

Answer 6

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

Answer 7

Пробелы в исходных файлах не влияют на работу пользователя. Как только бинарный файл скомпилирован, вот и все. Не имеет значения, если компилятору потребовалось delta-t больше времени для анализа вашего исходного кода, потому что было миллионы комментариев.