Влияют ли имена методов / параметров на то, сколько памяти занимает стек? - PullRequest
0 голосов
/ 27 января 2019

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

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

public static int convertSomeIntegerValueToSomeOtherIntegerValueByMethodOfDividingTheOriginalIntegerByTwoAndRoundingTheOutputBecauseItIsAnInteger(int veryVerboseIntegerValueWithAVeryLongParameterNameSoItCanBeDividedByTwo){
    return veryVerboseIntegerValueWithAVeryLongParameterNameSoItCanBeDividedByTwo/2;
}
public static int divTwo(int a){
    return a/2;
}

Есть ли разница между этими двумя методами, кроме размера файла исходного кода?

Кроме того, делают ли эти имена методов скомпилированный код больше?

1 Ответ

0 голосов
/ 27 января 2019

Нет. Это никак не влияет на использование памяти.

Вещи в стеке разрешаются исключительно на основе их "позиции" относительно кадра стека.

Имена методов и классов, конечно, хранятся где-то (в метаданных класса), но это не влияет на использование памяти (кроме загрузки самого класса - class , обратите внимание, это так не влияет на использование памяти при создании экземпляров).

Имена параметров и имена переменных не сохраняются вообще, если вы не включили символы отладки во время компиляции.

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

Кроме того, делают ли эти имена методов скомпилированный код больше?

Да. Но это не имеет значения в великой схеме вещей.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...