Или функция с более коротким именем более эффективна, чем одна и та же функция с более длинным именем? Почему или почему?
Лично я думаю, что это будет более эффективно, но недостаточно эффективно, чтобы заставить нас заботиться об этом, просто догадаться.
Нет разницы в производительности, поскольку эти имена не имеют значения на уровне машины. Компилятор обработает эти имена, так что это совсем не повлияет на вашу программу.
Названия функций могут быть превращены в метки (что не повлияет на производительность во время исполнения), и имена переменных, вероятно, будут заменены операциями реферирования или стека (независимо от имени, которое вы используете). На этом уровне ОС использует (и прыгает) адреса памяти, а не имена.
Более длинные имена символов могут — когда-либо так немного замедлить компиляцию, но длина символа не влияет на время выполнения.
В некоторых реализациях интерпретаторов может влиять длина имени символа, но не большинство современных: они обычно выполняют шаг "компиляции", который удаляет имена символов из рассмотрения, среди других обработок.
Я использовал 1972 настольный компьютер HP с интерпретированным BASIC. В руководстве пользователя предлагается использовать короткие имена символов для скорости и сохранения памяти.
Чтобы ответить на письмо вопроса:, функция с длинным именем будет точно такой же эффективной, как и с коротким именем, если только она не называет себя рекурсивно (и в редких случаях при этом).
Чтобы ответить на дух вопроса (конечно, угадывая его): код с использованием длинных идентификаторов в исходном коде на подавляющем большинстве современных языков, работающих на современных компьютерах, даже тех, которые обычно считаются " интерпретируется не менее эффективно, чем код с короткими идентификаторами.
Общий ответ, с (в порядке, несколько надуманным) исключениями ниже:
Скомпилированные языки: символы добавляются в таблицу символов во время компиляции. Размер и сложность таблицы символов влияют на время выполнения этапа компиляции, но не на собственную среду выполнения программы.
Интерпретированные языки: символы добавляются в словарь времени инкрементации, а время, необходимое для нахождения символа, обычно изменяется с частотой O (n), где n - это длина символа.
Скомпилированные языки: для одного возможного исключения, выполните динамическую загрузку и интроспекцию.
Например, в C on * nix вы можете вызвать функцию dlopen(), чтобы открыть общий объект, затем вызвать функцию dlsym() для поиска данных или подпрограмм в этом объекте по имени. Это вызывает поиск таблицы символов объекта по имени. Если это основная часть вашей программы, то ваша программа может закончиться сложностью O (n) по отношению к длине объектов. Однако на практике загрузка таких объектов выполняется только для загрузки модульных модулей или плагинов во время инициализации, и поиски на самом деле не так уж много. Конечно, длина символов в вашей собственной программе все равно не повлияет на время выполнения.
Интерпретированные языки: подавляющее большинство современных интерпретируемых языков выполняют некоторые серьезные оптимизации и токенизации, поэтому, в конце концов, ссылаясь на длинный идентификатор или короткий, может быть эквивалентен на 100%. Хеширование, ограничения длины и т.д. Все упрощают. Это требует дополнительного времени (иногда в микросекундах, на современных компьютерах) для анализа более длинного идентификатора, и в зависимости от языка это может выполняться каждый раз, когда программа запускается, но до одного раза за запуск программы. Если вы не выполняете много eval s или огромную интроспекцию, вы не должны видеть проблему. Даже тогда, в случае Python, интроспекция dict и dict использует хеширование для поиска ключей, поэтому время выполнения увеличивается с количеством символов, а не их длиной.
Но скомпилировано или интерпретировано? Чем больше вы смотрите, тем меньше понятных языков вы найдете сегодня. Python упоминался в комментариях, но Python компилирует исходный код в байт-код и внутренне ссылается на идентификаторы с помощью токенов, а не на их полные имена. Механизмы JavaScript делают очень похожие вещи, в зависимости от конкретной реализации. Даже (большинство) 8-разрядных БАЗИСов восьмидесятых выполняли шаги токенизации, чтобы программа не хранилась в текстовой форме в памяти (это сохраняло как память, так и циклы ЦП, а не огромные запасы на 3 МГц, 64 КБ компьютеров), но в промежуточной форме легко интерпретируется. Имена переменных будут помещены в словарь, а токены (обычно адреса), используемые для ссылки на них. Листинг программы будет эффективно де-токенизировать ее для отображения.
Эффективный с точки зрения чего? Память, используемая во время выполнения, память, используемая во время компиляции, вычисление, выполняемое во время выполнения, вычисление, выполняемое во время компиляции, размер исполняемого файла или что-то еще?
Более длинные идентификаторы потребуют магически большего количества вычислений и памяти во время компиляции. Кроме того, исполняемый файл отладки содержит некоторые символы, поэтому более длинные идентификаторы могут влиять на размер отладочного исполняемого файла.
В терминах вычисления времени выполнения и использования памяти нет, длина идентификаторов не имеет никакого эффекта, кроме косвенных эффектов от ранее упомянутых различий.
Это будет зависеть от платформы, на которую вы нацеливаетесь, при условии, что вы имеете в виду текущую производительность исполняемых файлов.
Например, функции Symbian OS в DLL просматриваются по порядковым номерам, поэтому имя никогда не является частью двоичного файла. Таким образом, ответ отрицательный, он не эффективнее, поскольку он не имеет никакого значения, поскольку он никогда не появляется в целевом изображении.