On GAS fees (on code refactoring)

[Hiren879]

Will the below code refactor affect the GAS fees paid by the transaction?

SimpleStorage simpleStorage = simpleStorageArr[_simpleStorageIndex]; return simpleStorage.retrieve();

Vs

return simpleStorageArr[_simpleStorageIndex].retrieve();

As per my understanding, this should not affect the GAS fees because this is just code refactoring for readability purposes.
But still, I want to clarify from the community if this understanding is correct.

[krakxn]

The latter is less gas intensive relative to the former.

Why? Because in the former, we are declaring and initializing simpleStorage, which is a storage variable and hence, will consume extra gas. This is precisely why the latter is less gas-intensive as there is no variable declaration (which consumes gas).

memory (less gas intensive than storage, as values are discarded) keyword could be used for the former, but it is important to note that the latter is still cheaper because there is no reference to the memory data location.

[Hiren879]

I am not sure but logically simpleStorage should not be a storage variable because it is initialized inside the function so its life should be only limited to the function's scope. Once it will return the value from the function it should be killed.

And if this is true then I think while coding in Solidity, one should always keep in mind not to declare many variables and call inline functions wherever possible.

Again, for the first point, I need to check more. I am still learning the solidity.
But thanks for your answer, it really helped.

[krakxn]

No, there is no subjectivity involved here :)

Even if the scope itself is not global (e.g. specific to a function), if it is not explicitly marked otherwise (e.g. memory) it will be a storage variable. "Once it will return the value from the function it should be killed." -- it is not killed, it is part of the contract's storage stack and hence, will not be killed. Of course, if it is marked memory it will be killed after using it.

What I would recommend is to just get the logic correctly first, then on a further inspection you could optimize subtleties such as these to optimize for gas; elsewise you will take on a headache optimizing everything which may or may not be not needed after the complete code is written.

[Hiren879]

I see. This helped me to keep away Java's (JVM) function concepts from the solidity's (EVM) function concept.
Java function & solidity function is not working with the same logic/understanding.

From this my take away learning is:

• if you are writing any logic inside the function in solidity, try to use memory if usage is local else by default solidity will mark it as storage and may cost you more GAS.

[krakxn]

It essentially is an OOP-language, just w/ the added twist of blockchain-specific (context-specific) parameters and such as these.

You will find no issues whatsoever transitioning once you are used to the latter, and will be second-nature to you (similar to an OOP lang. like Java)