Чи впливають назви змінних на ефективність веб-сайтів?


10

Чи впливають імена змінних на ефективність веб-сайту? Я знаю, що це буде дуже мало, але все ж чи може хтось із причин не вибрати довге ім'я змінної в аспекті продуктивності?


2
Поясніть, будь ласка, своє запитання - де ця змінна і якою мовою вона написана?
Люк Грем

16
Вам ніколи не слід вибирати короткі та нелогічні імена змінних, якщо ваші міркування є (сумнівним) виконанням. Вихідний код є для того, щоб інші люди його читали, а не для задоволення комп'ютерів та їх мікроскопічного підвищення продуктивності.
Michael JV

я використовую PHP ..
Avinash

2
... А ви володієте xpertdeveloper.com?
Джим Г.

3
Привіт, Авінаш, ти можеш пояснити у своєму питанні своє обгрунтування думки, що це може бути так?

Відповіді:


17

Чи може хтось із них навести причини невибору довгої назви змінної в аспекті продуктивності?

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

Загалом, ви хочете використовувати короткі описові назви змінних, оскільки їх легше читати. Уявіть, якщо вам доведеться ігнорувати свій код протягом 10 років, а потім знову все зрозуміти. Ви б краще прочитали "getInput" або "getInputFromUserWhoInputsStringOrElseInformReaderOfError"? (перебільшення курсу: P)

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


6
для читання довгих імен краще, якщо ви знайдете "getInputFromUserWhoInputsStringOrElseInformReaderOfError", вам не потрібно читати документацію, що ця функція, якщо ви знайдете "getInput", яка вам потрібна. А через 10 років документація буде неправильною, або неповною, або відсутньою. getInputFromUserWhoInputsStringOrElseInformReaderOfError, безумовно, довго, але краще зрозуміти, що це довго (і мені байдуже, що жінки кажуть, що розмір не має значення).
Дайній

Я не згоден у цьому випадку. Я думаю, що лише прочитавши код, було б досить легко зрозуміти, що робить getInput (), особливо якщо після цього він друкує "недійсний ввід" чи щось. Однозначно є випадки, коли довше ім’я може бути кращим - я його відредагую!
BlackJack

ofc це залежить від контексту, але, на мій досвід, довше ім'я краще (але не так довго, як getInputFromUserWhoInputsStringOrElseInformReaderOfError). І контекст, дійсно важливий, оскільки file.read () швидше, ніж file.readAllFileAsByteArray (). Але, як я вже говорив, звичайно, довша назва IMHO надає більше інформації.
Дайній

1
Якщо документація неправильна, неповна або відсутня, база коду все одно приречена.
Крістофер Махан

2
Це відповідає на запитання, яке не задавали.

16

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

Змінні - це символи, не більше того. Вони замінюють шістнадцяткові значення іменами, щоб програмістам було легше зрозуміти, що вони роблять. Таким чином, підвищення продуктивності не буде, вибираючи короткі імена змінних.

Це означає, що ви можете отримати незначні (і я говорю мікроскопічні) поліпшення часу компіляції та першої інтерпретації JIT, але це лише тому, що парсер займає кілька циклів процесора менше, щоб прочитати ім'я змінної. Це разова вартість і є статистично незначною, коли турбуєтесь про продуктивність.


11
Хоча ваша відповідь правильна для програмування додатків, ОП посилається на веб-сайти, і тому є шанс, що він використовує інтерпретовану мову. У такому випадку код потрібно буде прочитати з файлу, а потім інтерпретувати. У цьому випадку для завантаження та розбору довше ім’я змінної буде потрібно більше часу. Однак підвищення продуктивності буде незначним і масово компенсується зайвими клопотами програмісту з читання та розуміння коду.
Гевін Коутс

1
@Gavin Правильно і для інтерпретованих мов - "Перша інтерпретація JIT". Більшість інтерпретованих мов зараз компілюються під час виконання, а не рядка за рядком, AFAIK.
Майкл К

1
Майкл - для компіляції файл спочатку потрібно прочитати в пам'яті. Цей процес займе більше часу, залежно від довжини файлу. Більш довгі імена змінних = довші файли.
Гевін Коутс

Питання позначено як PHP. PHP ще не має JIT - це буде новою особливістю випуску 8.0, запланованого на кінець цього року. Він компілює в байт-код перед виконанням, і байт-код, як правило, кешується на веб-серверах, щоб використовуватись у кількох запитах.
bdsl

8

Якщо ви не використовуєте кеш оп-коду (також відомий як "прискорювачі PHP"), це дійсно має вплив. Але цей вплив настільки низький, що його можна нехтувати. Якщо ви використовуєте кеш оп-коду, це вплив нульовий.


1
і якщо ви настільки дбаєте про продуктивність, що ви вважаєте скорочення імен змінних для отримання кількох циклів, використання кешу оп-коду було б злочинним ... і рекомендується перехід на мову компіляції на зразок C.
СФ.

Але очевидно, що вплив є накопичувальним, тому чим більший додаток, тим більший вплив, правда?
n00dles

Zend Opcache постачається з PHP вже кілька років, тому всі повинні використовувати його. Я думаю, що це, як правило, включено за замовчуванням.
bdsl

3

Хоча Майкл правильний для програмування програм, ваше питання стосується веб-розробки з PHP, що є інтерпретованою мовою. У такому випадку код потрібно буде прочитати з файлу, а потім інтерпретувати. У цьому випадку для завантаження та розбору довше ім’я змінної буде потрібно більше часу.

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

Як зазначає BlackJack, довші імена можуть бути набагато складнішими для розуміння та потребують багато додаткових зусиль для набору тексту (і вони значно схильні до друкарських помилок). Хоча може бути невеликий приріст продуктивності, це не виправдовує зайвих клопотів, створених для програміста. Таким чином, переважні короткі, стислі та легкі для розуміння імена змінних.

Отже, коротше, не переживайте за назву змінної довжини, а натомість зосередьтесь на написанні чистого, змістовного коду.


1

Можливо :

Код сервера, як правило, компілюється, і довжина імені змінної не впливатиме на нього із зазначених причин. Однак якщо ім'я змінної використовується для побудови розмітки різних рядкових операцій. Оскільки відповідь HTTP (містить розмітку / повернуті json / повернуті дані) більша, це займе трохи більше часу, хоча різниця буде незначною. Якщо JavaScript не буде мінімізовано, це буде більший файл, який займе більше часу для подорожі до клієнта.

Окрім мінімізації файлів JavaScript, будь-які зусилля з оптимізації веб-додатку / веб-сайту будуть краще витрачені на інші аспекти.


1

Так, це буде, але не в тому сенсі, про який ви думаєте.

З поганими іменами змінних розробники легко заплутаються у вихідному коді. Це буде важко читати і важко зрозуміти.

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

Ім'я змінної не матиме абсолютно ніякого впливу під час виконання, і зовсім незначне під час компіляції. Але невірні імена неминуче призводять до поганої продуктивності, оскільки ніхто не розуміє код, і він виявляється в групі зламу один на інший, що робить щоразу гірше.

Прочитайте їх, щоб знати про гарне ім’я змінної: http://tottinge.blogsome.com/meaningfulnames

Зауважте, що якщо ви відчуваєте потребу в дуже довгій імені змінної, це означає, що ваш код погано зорієнтований. Ім'я змінної завжди виражається в контексті: простір імен, ім'я класу, ім'я файлу, папка, ім'я функції тощо. Таким чином, якщо ім'я має бути довгим, щоб бути явним, це означає, що те, що ви намагаєтесь назвати DOESN ' Т БЕЛОН ТУТ . У цьому випадку подумайте про те, щоб помістити цей код у відповідне місце або створити його, якщо він ще не існує.


0

Відповідь, очевидно, так, щодо php.

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


1
Але ви помиляєтесь. Будь-який порядний інтерпретатор php розбере код лише один раз. Хлопці, які пишуть перекладачі php, не дурні.
gnasher729

@ gnasher729 Ви робите припущення про те, як працює перекладач або весь сервер, і ніколи цього не слід робити. Навіть якщо він буде аналізувати лише один раз за цикл, він може повторно аналізувати кожен пробіг і не кешувати проаналізований подання (інші системи це робитимуть, але ви не можете знати заздалегідь). І взагалі, чим більше байт сценарій, тим довше буде потрібно розбирати. Отже, Діортотіс взагалі не помиляється, він може помилятися лише щодо конкретної системи.
Мекі

0

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

Отже, щоб відповісти на ваше запитання ("чи впливає це на продуктивність"): Так, але не так, як вам подобається.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.