You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i noticed that the gas cost of creationCodeFor for ~1500 bytes is ~7.2k gas
i'm assuming this is due to the 2x abi.encodePacked calls that would be allocating and building new bytes in memory each time
i saw creationCodeFor above 90k gas for about 20kb of data
i was thinking that if SSTORE2 could setup a region in memory with all the creation code prefilled followed by X bytes, and return a pointer to the start of X bytes, then devs willing to use assembly could potentially efficiently populate the X bytes themselves (a gas cost they would have to pay either way) then ask SSTORE just to deploy the result without further processing
i'll attempt to do this myself locally and report back on whether the approach helps
FYI the deploy cost of the same 1500 bytes was ~327k gas, so the overhead is ~2%
The text was updated successfully, but these errors were encountered:
i noticed that the gas cost of creationCodeFor for ~1500 bytes is ~7.2k gas
i'm assuming this is due to the 2x abi.encodePacked calls that would be allocating and building new
bytes
in memory each timei saw creationCodeFor above 90k gas for about 20kb of data
i was thinking that if SSTORE2 could setup a region in memory with all the creation code prefilled followed by X bytes, and return a pointer to the start of X bytes, then devs willing to use assembly could potentially efficiently populate the X bytes themselves (a gas cost they would have to pay either way) then ask SSTORE just to deploy the result without further processing
i'll attempt to do this myself locally and report back on whether the approach helps
FYI the deploy cost of the same 1500 bytes was ~327k gas, so the overhead is ~2%
The text was updated successfully, but these errors were encountered: