Влияют ли имена переменных на производительность веб-сайтов?

10

Влияют ли имена переменных на производительность сайта? Я знаю, что это будет очень малое число, но все же может ли кто-нибудь указать причины, по которым не следует выбирать длинное имя переменной в аспекте производительности?

Авинаш
источник
2
Пожалуйста, уточните свой вопрос - где эта переменная и на каком языке она написана?
Люк Грэм
16
Вы никогда не должны НИКОГДА выбирать короткие и нелогичные имена переменных, если ваши рассуждения (сомнительны). Исходный код предназначен для чтения другими людьми, а не для удовлетворения потребностей компьютеров и их микроскопического прироста производительности.
Michael JV
я использую PHP ..
Avinash
2
... а у вас есть xpertdeveloper.com?
Джим Г.
3
Привет, Авинаш, можешь ли ты объяснить в своем вопросе, почему ты считаешь, что это так?

Ответы:

17

Может ли кто-нибудь представить причины, по которым не следует выбирать длинное имя переменной в аспекте производительности?

Майкл покрыл ответ (т.е. нет), но имена переменных влияют на производительность программиста . Если вы привлекаете нового разработчика или кого-то, кто не знаком с кодом, то наличие длинных и / или запутанных имен переменных может отвлекать и замедлять процесс понимания.

В общем, вы хотите использовать короткие, описательные имена переменных, потому что их легче читать. Представьте, что вам нужно игнорировать свой код в течение 10 лет, а затем снова все понять. Вы бы предпочли прочитать «getInput» или «getInputFromUserWhoInputsStringOrElseInformReaderOfError»? (преувеличение конечно: P)

Однако бывают случаи, когда более длинное имя может быть полезным. Например, getBirthdayInput () будет гораздо более информативным, чем getInput (). Вы хотите упростить до некоторой степени, но упрощение также может быть проблематичным.

Блэк Джек
источник
6
для чтения длинных имен лучше, если вы найдете "getInputFromUserWhoInputsStringOrElseInformReaderOfError", вам не нужно читать документацию, что это за функция, если вы найдете "getInput", который вам нужен. И через 10 лет документация будет неправильной, неполной или отсутствующей. getInputFromUserWhoInputsStringOrElseInformReaderOfError, безусловно, слишком длинная, но лучше понять, что это длинная (и мне все равно, что женщины говорят, что размер не имеет значения).
Дайний,
Я не согласен в этом случае. Я думаю, просто читая код, было бы довольно легко понять, что делает getInput (), особенно если он печатает «неверный ввод» или что-то сразу после этого. Хотя определенно бывает, что длинное имя может быть лучше - я его отредактирую!
Блэкджек,
ofc это зависит от контекста, но по моему опыту более длинное имя лучше (но не так долго, как getInputFromUserWhoInputsStringOrElseInformReaderOfError). И контекст действительно важен, так как file.read () работает быстрее, чем file.readAllFileAsByteArray (). Но, как я уже сказал, обычно ИМХО более длинное имя дает больше информации
Дайний,
1
Если документация неверна, неполна или отсутствует, кодовая база все равно обречена.
Кристофер Махан
2
Это ответ на вопрос, который не был задан.
16

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

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

Тем не менее, вы можете получить незначительные (а я говорю о микроскопических) улучшения во время компиляции и первой интерпретации JIT, но это только потому, что синтаксический анализатор занимает несколько циклов ЦП, чтобы прочитать имя переменной. Это единовременная стоимость, и она статистически незначима, если беспокоиться о производительности.

Майкл К
источник
11
Хотя ваш ответ верен для прикладного программирования, ОП ссылается на Веб-сайты, и поэтому есть вероятность, что он использует интерпретированный язык. В таком случае код должен быть считан из файла, а затем интерпретирован. В этом случае более длинное имя переменной будет загружаться и анализироваться дольше. Однако выигрыш в производительности будет незначительным и значительно компенсируется дополнительными хлопотами для программиста по чтению и пониманию кода.
Гэвин Коутс
1
@Gavin Это верно и для интерпретируемых языков - «JIT first translation». Большинство интерпретируемых языков теперь компилируются по мере их исполнения, а не построчно, AFAIK.
Майкл К
1
Майкл - для того, чтобы скомпилировать, файл сначала должен быть прочитан в память. Этот процесс займет больше времени в зависимости от длины файла. Более длинные имена переменных = более длинные файлы.
Гэвин Коутс
Вопрос помечен как PHP. В PHP пока нет JIT - это будет новая функция релиза 8.0, запланированная на конец этого года. Он компилируется в байт-код перед выполнением, и байт-код обычно кэшируется на веб-серверах для использования в нескольких запросах.
bdsl
8

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

Vartec
источник
1
и если вы так сильно заботитесь о производительности, что рассматриваете укорочение имен переменных для получения нескольких циклов, отказ от использования кэша кода операции будет преступным ... и рекомендуется переключиться на скомпилированный язык, такой как Си.
SF.
Но очевидно, что это влияние накапливается, поэтому чем больше приложение, тем больше влияние, верно?
17
Zend Opcache поставляется с PHP уже несколько лет, поэтому каждый должен его использовать. Я думаю, что это вообще включено по умолчанию.
BDSL
3

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

Однако при этом производительность будет незначительной и, вероятно, будет составлять доли миллисекунды для всего сценария. Вы всегда можете попробовать его с помощью образца сценария и использовать метод синхронизации, такой как подробно описанный по адресу http://www.developerfusion.com/code/2058/determine-execution-time-in-php/, но, вероятно, это не так начните отсчет времени до того, как файл будет прочитан. Кроме того, время выполнения между повторными попытками будет значительно больше, чем разница между длинами имен переменных, поэтому вам потребуется выполнить значительное количество повторных попыток и взять среднее значение каждой из них, прежде чем вы сможете получить отдаленно значимое среднее.

Как указывает Блэкджек, более длинные имена могут быть намного сложнее для понимания, и для их набора требуется много дополнительных усилий (и они гораздо более подвержены опечаткам). Хотя прирост производительности может быть незначительным, это не оправдывает дополнительных хлопот, созданных для программиста. Как таковые, короткие, краткие и простые для понимания имена переменных являются предпочтительными.

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

Гэвин Коутс
источник
1

Может быть :

Код сервера обычно компилируется, и длина имени переменной не влияет на него по указанным причинам. Однако, если имя переменной используется для построения разметки различных строковых операций. Поскольку HTTP-ответ (содержащий разметку / возвращенные json / возвращенные данные) больше, это займет немного больше времени, хотя разница будет незначительной. Если JavaScript не уменьшен, это будет файл большего размера, который займет больше времени для поездки к клиенту.

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

StuperUser
источник
1

Да, будет, но не в том смысле, о котором вы думаете.

С плохими именами разработчиков, разработчики легко запутаются в исходном коде. Это будет трудно читать и трудно понять.

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

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

Прочитайте их, чтобы узнать о хорошем имени переменной: http://tottinge.blogsome.com/meaningfulnames

Обратите внимание, что если вам нужно очень длинное имя переменной, это означает, что ваш код плохо спроектирован. Имя переменной всегда выражается в контексте: пространство имен, имя класса, имя файла, папка, имя функции и т. Д. Таким образом, если имя должно быть длинным, чтобы быть явным, это означает, что то, что вы пытаетесь назвать, ДАЕТ « Т ЧЕТ ЗДЕСЬ . В этом случае подумайте о размещении этого кода в соответствующем месте или создайте это место, если его еще нет.

deadalnix
источник
0

Ответ, очевидно, да, в отношении php.

Ответы, которые говорят, что это не будет иметь значения, не обязательно правильны. Например, у меня есть небольшой скрипт php, всего несколько строк, но он должен зацикливаться примерно 1 950 000 раз, прежде чем завершит свою работу, поэтому, хотя один запуск скрипта может не быть замечен, эти доли секунды существенно складываются, когда зацикливание много раз

Diorthotis
источник
1
Но вы не правы. Любой приличный интерпретатор php проанализирует код только один раз. Ребята пишущие php-интерпретаторы не дураки.
gnasher729
@ gnasher729 Вы делаете предположения о том, как работает интерпретатор или весь сервер, и вы никогда не должны этого делать. Даже если он будет анализироваться только один раз за прогон, он может пересматриваться при каждом прогоне и не кэшировать проанализированное представление (другие системы будут делать это, но вы не можете знать заранее). И, как правило, чем больше байтов скрипта, тем дольше он будет анализироваться. Таким образом, Диортотис не ошибается вообще, он / она может ошибаться только в отношении конкретной системы.
Mecki
0

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

Итак, чтобы ответить на ваш вопрос («влияет ли это на производительность»): Да, но не так, как вам нравится.

gnasher729
источник