Transaction Gas Problem Solidity

Question

 function x(uint256 _value) public {
    limit += _value;
    if(limit >= 5){
    myMethod();
    limit = 0;
    }
 }

I have a method like that(x function). if limit is smaller then 5 everything is OK but the last caller (for example contract has 3 and he will send 2-3 value) it will continue to if statement and it will run myMethod(); so the last caller should pay more gas then other callers. myMethod(); is calling another method from another contract with importing and giving contract address. (is it mean more gas?)

I want to do if the code will continue to if statement I want to pay gas fee of myMethod(); Is it possible?

  function x(uint256 _value) public {
    limit += _value;
    if(limit >= 5){
    msg.sender = address(this); // or msg.sender = owner;
    myMethod();
    limit = 0;
    }
  }

Or can I create automatic function without call on the contract. Directly :

if(limit>=5){
myMethod();
}

Without method, directly call on contract //I know it is not possible but is there any diffrent method for that?

Answer 1

This property is read-only. You can't set. The sender always pays for gas.

msg.sender = address(this); // or msg.sender = owner;

You have a variable execution cost but the rule still applies. The sender pays for gas.

myMethod(); is calling another method from another contract with importing and giving contract address. (is it mean more gas?)

Is it mean more gas?

Marginally more. There are ops for packing the arguments and the response and unpacking on both sides, looking up the other contract's address and so on but these are mostly cheap operations if the address of the foreign contract is hard-coded. More if the address needs to be read from storage.

The uneven gas cost is a factor for many contracts. Branching does that. Generally, be aware of the fairness of the distribution but don't obsess over it as it is often perfectly acceptable for users to pay a little extra if extra work happens to need to be done.

It is usually not possible to know the exact cost in advance because clients cannot know their place in the mined transaction order. If users A, B, C, D and E send transactions more or less simultaneously and with equal gasPrice, the odds of any particular one coming in fifth are roughly even. This presents a challenge to clients that attempt to estimate gasPrice based on a "dry run" simulation - the actual cost depends not on current conditions but conditions when the transaction is mined. This can lead to aborted transactions.

It can be wise to pad the gas supplied with a little extra to cover the worst-case scenario. The client-side transaction object can contain { gas: amount }. You can set that to the worst case - to be sure there is always enough. Any excess gas is always returned to the user. Most users will take the gas displayed by MetaMask etc. as gospel and realize a refund took place, so you will usually want the minimum viable padding.

Hope it helps.