Что-нибудь можно получить от коротких имен переменных?

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

И если да, то в каких ситуациях было бы разумно рассмотреть это?

Заметка

Я никоим образом не защищаю короткие имена переменных, мне просто интересно, пожалуйста (пере) прочитайте вопрос.

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

Источник

6 ответов

Решение

Есть проблема с "как python", потому что не все интерпретируемые языки одинаковы.

С чисто интерпретируемым языком это будет иметь большее влияние, чем с таким как Python, у которого есть этап перед компиляцией. Строго говоря, это не является языковой разницей (у вас может быть один движок Javascript, который предварительно компилируется, и тот, который нет), но это влияет на ответ на этот вопрос.

Протягивая "как python", чтобы включить каждый интерпретируемый язык, я бы сказал, что ответ "да, для некоторых из них, по крайней мере, некоторое время". Следующий вопрос "сколько".

С 1997 по начало 1998 года я работал над довольно сложным javascript-кодом, в котором использовались некоторые новые функции Netscape Navigator 4 и Internet Explorer 4. Это был огромный файл javascript для того времени, когда преобладали коммутируемые соединения. означает, что каждый килобайт считается с точки зрения скорости сайта.

По этой причине мы использовали скрипт минимизатора. Главное, что это сделало, было переписать переменные, чтобы они были короче (lastHeight становится a, userSel becmomes b и так далее).

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

Так что да, если мы поместим Javascript в категорию "как python" в части интерпретации, тогда это может иметь значение при следующих условиях:

  1. Он работал на Pentium, Pentium Pro и 486 (тогда Pentium II был выпущен, но у нас его не было). Я получил новую машину на полпути через проект, что означало, что я перешел с 133 МГц на 166 МГц.
  2. Это был довольно большой кусок неприятного зацикливания (большая часть сценария не имела заметной разницы).
  3. Он был запущен на скриптовом движке 15 лет назад, и никаких улучшений производительности скриптового движка с тех пор не было.

И это все равно не имело особого значения.

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

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

Источник

Нет-нет-нет-нет-нет.

Нет.

Используйте читаемые имена, а не короткие имена. Разница в производительности абсолютно пренебрежимо мала.

$ python -m timeit "i = 5" "i *= i"
10000000 loops, best of 3: 0.0938 usec per loop

$ python -m timeit "is_there_anything_to_be_gained_from_short_variable_names = 5" "is_there_anything_to_be_gained_from_short_variable_names *= is_there_anything_to_be_gained_from_short_variable_names"
10000000 loops, best of 3: 0.0927 usec per loop

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

Источник

Если вы подразумеваете интерпретируемые языки под пометкой "такие языки, как Python", то да, это будет иметь значение, так как синтаксический анализ может занять несколько больше времени. Разница не заметна, я бы сказал.

Я полностью согласен с Nightcracker, хотя; не делай этого Сделайте ваш код читабельным для человека. Позвольте парсеру / компилятору управлять читаемостью для машины.

Запомните правила оптимизации:

  1. Не делай этого.
  2. (Только для экспертов) пока не делай этого.
Источник

Вы должны использовать короткие имена переменных только для индексов с коротким циклом и когда переменная недолговечна.

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

Источник

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

Источник

Исходя из ответа orlps, я посчитал, что классы Python используют словарь для поиска, поэтому я подумал, есть ли какое-то преимущество в этом отношении.

import timeit

A = """
class A_CLASS_WITH_A_LONG_NAME:
    def a_function_with_a_long_name(self):
        return 1

A_CLASS_WITH_A_LONG_NAME().a_function_with_a_long_name()
"""

B = """
class A:
    def a(self):
        return 1

A().a()
"""

print(timeit.timeit(stmt = A, number = 1000000))
print(timeit.timeit(stmt = B, number = 1000000))

Мы получаем цифры:

  • Long = 12.362802280999858
  • Short = 11,445085418999952

Которые примерно на 8% отличаются.

Запуск внутри модуля (number = 100000000) Вместо того, чтобы использовать timeit:

  • Long = 24,87908697128296
  • Короткий = 24,695187091827393

Которые примерно на 1% отличаются.

Я хотел бы заключить, что может быть разница с встроенным кодом или тонкостями timeit профилировщик (timeit кажется, примерно в 50 раз медленнее), но Cpython, похоже, хорошо справляется с оптимизацией любых различий. Я не могу сказать, будет ли это по-прежнему справедливо для класса с большим количеством членов в качестве dict будет больше ведер.

Источник
Другие вопросы по тегам